Subject: Re: [Netconf] Minutes 26-Oct: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts

From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
Date: Wed, 2 Nov 2016 17:40:59 +0000

Dear NETCONF WG,

the co-chairs would like to thank Eric Voit and the notification team for their essential discussion and the valuable work they are doing.

However we also would like to clarify that the reported meeting below is an adhoc-meeting of a group of volunteers and not an official WG virtual meeting.
As such the agreements achieved in this meeting series are limited to the meeting attendees and don't reflect WG consensus.
As per IETF-process NETCONF WG maillist involving all WG members is the panel which will declare WG consensus based on the WG drafts the notification team is preparing.

@All:
Please comment on the discussion results of the notification team meeting on the maillist. Such early comments are a good contribution to WG consensus preparation.
Please approach Eric if you want to be included in the adhoc-meetings of the notification team.

PS: Official WG virtual meetings are required to agree with the AD and need to be planned and announced by the co-chairs 1-2 weeks ahead of time.
We made the experience in the past that finding the appropriate time for a WG virtual meeting is very difficult. An adhoc-meeting OTOH can be organized much more easily.

Many Thanks,
Mehmet & Mahesh

From: Netconf [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, October 26, 2016 10:43 PM
To: [email-masked]' <[email-masked]>; [email-masked]
Subject: [Netconf] Minutes 26-Oct: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts

https://github.com/netconf-wg/yang-push/wiki/Minutes-2016-10-26

Meeting Materials

Attending

WebEx Recording<https://cisco.webex.com/ciscosales/lsr.php?RCID=1c507c6625ac4e74bfc425e650dc978b>
password: qAb6KumY

Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar Nilsen-Nygaard, Eric Voit, Tim Jenkins, Balazs Lengyel, Kent Watsen, Ambika Tripathy

Modifications to Latest 5277bis

  *   Alex, Eric, Alberto have updated model and draft. Look for latest shortly posted to IETF
     *   Definitions updated throughout from 5277 for Publisher (from Event Server) and Subscriber (from Client)
     *   Text simplifications/reductions
  *   Discussed on the call to still be mixed into the text. (upcoming update will include)
     *   Notifications: Remove added-to-subscription, and removed-from-subscription notifications.
     *   Dynamic Subscriptions: don't allow modification to streams or encoding for modify-subscription RPC.

Filters and Streams

  *   Reviewed Andy's proposal for a new filter type based on hierarchical event type metadata
     *   Seems like a good idea. The hard part will be defining the event hierarchy. That will play out in the IETF somewhat decoupled from subscriptions as it could be used for GET filter as well.
  *   Need for a new Draft including Metadata filtering
     *   There is not an existing YANG filter for Metadata. Nor is there a filter for metadata + subtree filtering. This needs to be solved for GET operations (i.e., this is not just about subscriptions).
  *   For populating the metadata: Subtrees will inherit the event-types of their parents, unless otherwise indicated via a deviations file.
  *   For metadata filters, there needs to be some mechanism that the on-change notification for metadata pushed data in the sequential order of operations on a device. For example, you want to push object metadata changes for before you see the same object's corresponding changes for datastore.
  *   Open question on filters: Are the capabilities in a filter type allowed to be mixed/matched to make a more complex union or intersection filter within a subscription?
     *   Eric recommendation: We don't allow application of multiple filters concurrently. Building a filter syntax for unions and intersections across filter types is interesting, but hard. Problematically it puts us in the business where we have to define what is possible (or not) via the combination of any two filter types. It would be simpler to leave the valid combinations of filter capabilities to any particular normative reference.
     *   We should advocate for a new IETF draft (above) which defines this.
  *   Streams
     *   Streams are optional, and will include NETCONF and custom-stream entries. We will not try to standardize any new IETF streams at this point.
     *   Metadata would allow filtering on OpState info (upcoming draft from the datastore design team). This would accomplish the same business objectives as what we were talking about previously with IETF standardized streams. Anyone who wants to meet those objectives prior to having a filter on OpState metadata can define their own custom-stream.

Partial/incremental push of periodic data

  *   Einar believes real world examples necessitate that a Publisher be able to partition and sequence the push updates.
     *   This means no need to aggregate a single push from different linecards
     *   Then able to load balance pushed for different objects with a different push timestamp.
  *   Belief that Anchor-time is not the right object to use for determining whether partial push updates are acceptable to be sent. Instead a new periodic type subscription object should be created. Perhaps "partial-push-accepted"?
  *   Proposal to be brought to mailing list (by Einar?) as people are worried about the extra complexity this will introduce. Topics to address include:
     *   A push update for a subscription with the partial-push-accepted flag = yes is not assumed to be a complete representation of the datastore, it just contains that set of objects/values at that particular time of a push update.
     *   Integrity across the datastore extract cannot be assumed.
     *   Can be used during negotiation if an internally consistent set of objects should not be assumed by the receiver.
     *   Push updates are accumulated across a known period established across a subscription, with the last value received being current. Object which is older than the period is assumed to be stale or deleted.
     *   Establish proper meaning of updates-not-sent flag.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 2 Nov 2016 19:01:37 +0000

Thanks Mehmet, this makes sense.  We in the design team fully understand these meetings are simply intended to develop material ready for wider NETCONF socialization.  In fact we will be bringing a host of items for more formal discussion at IETF97.

Our weekly design team meetings are welcome to anyone.  Ping me if interested.

Eric

From: Ersue, Mehmet, November 2, 2016 1:41 PM

Dear NETCONF WG,

@All:

Many Thanks,
Mehmet & Mahesh

From: Netconf [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, October 26, 2016 10:43 PM
To: [email-masked]' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [Netconf] Minutes 26-Oct: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts

Meeting Materials

Attending

Modifications to Latest 5277bis
*        Alex, Eric, Alberto have updated model and draft. Look for latest shortly posted to IETF
o   Definitions updated throughout from 5277 for Publisher (from Event Server) and Subscriber (from Client)
o   Text simplifications/reductions
*        Discussed on the call to still be mixed into the text. (upcoming update will include)
o   Notifications: Remove added-to-subscription, and removed-from-subscription notifications.
o   Dynamic Subscriptions: don't allow modification to streams or encoding for modify-subscription RPC.
Filters and Streams
*        Reviewed Andy's proposal for a new filter type based on hierarchical event type metadata
o   Seems like a good idea. The hard part will be defining the event hierarchy. That will play out in the IETF somewhat decoupled from subscriptions as it could be used for GET filter as well.
*        Need for a new Draft including Metadata filtering
o   There is not an existing YANG filter for Metadata. Nor is there a filter for metadata + subtree filtering. This needs to be solved for GET operations (i.e., this is not just about subscriptions).
*        For populating the metadata: Subtrees will inherit the event-types of their parents, unless otherwise indicated via a deviations file.
*        For metadata filters, there needs to be some mechanism that the on-change notification for metadata pushed data in the sequential order of operations on a device. For example, you want to push object metadata changes for before you see the same object's corresponding changes for datastore.
*        Open question on filters: Are the capabilities in a filter type allowed to be mixed/matched to make a more complex union or intersection filter within a subscription?
o   Eric recommendation: We don't allow application of multiple filters concurrently. Building a filter syntax for unions and intersections across filter types is interesting, but hard. Problematically it puts us in the business where we have to define what is possible (or not) via the combination of any two filter types. It would be simpler to leave the valid combinations of filter capabilities to any particular normative reference.
o   We should advocate for a new IETF draft (above) which defines this.
*        Streams
o   Streams are optional, and will include NETCONF and custom-stream entries. We will not try to standardize any new IETF streams at this point.
o   Metadata would allow filtering on OpState info (upcoming draft from the datastore design team). This would accomplish the same business objectives as what we were talking about previously with IETF standardized streams. Anyone who wants to meet those objectives prior to having a filter on OpState metadata can define their own custom-stream.
Partial/incremental push of periodic data
*        Einar believes real world examples necessitate that a Publisher be able to partition and sequence the push updates.
o   This means no need to aggregate a single push from different linecards
o   Then able to load balance pushed for different objects with a different push timestamp.
*        Belief that Anchor-time is not the right object to use for determining whether partial push updates are acceptable to be sent. Instead a new periodic type subscription object should be created. Perhaps "partial-push-accepted"?
*        Proposal to be brought to mailing list (by Einar?) as people are worried about the extra complexity this will introduce. Topics to address include:
o   A push update for a subscription with the partial-push-accepted flag = yes is not assumed to be a complete representation of the datastore, it just contains that set of objects/values at that particular time of a push update.
o   Integrity across the datastore extract cannot be assumed.
o   Can be used during negotiation if an internally consistent set of objects should not be assumed by the receiver.
o   Push updates are accumulated across a known period established across a subscription, with the last value received being current. Object which is older than the period is assumed to be stale or deleted.
o   Establish proper meaning of updates-not-sent flag.

---

From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
Date: Wed, 2 Nov 2016 19:33:20 +0000

Hi Eric,

a Design Team has a particular meaning at IETF. The members of an IETF DT are nominated by the AD and WG co-chairs.
An IETF DT generally works as a closed group and comes up after a scheduled time period with a draft for WG review.

Although the end result is similar the team you guys have set up is a group of volunteers discussing the notification drafts.
But also the Notification Team is open to other experts which would like to contribute.

I believe the Notification Team can be much more efficient based on the early comments and feedback they are asking the WG to provide.

Mehmet

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: Wednesday, November 02, 2016 8:02 PM
To: Ersue, Mehmet (Nokia - DE/Munich) <[email-masked]>; [email-masked]
Subject: RE: [Netconf] Minutes 26-Oct: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts

Eric

@All:

Many Thanks,
Mehmet & Mahesh

Meeting Materials

Attending

---

From: Andy Bierman <[email-masked]>
Date: Wed, 2 Nov 2016 12:40:13 -0700

Hi,

Perhaps it would be better if the ad-hoc group did not post any meeting
minutes
to the WG.  There is no official content in them but they seem to be
causing a problem anyway.
I suggest that no minutes be posted at all.  Just post the drafts and the WG
can comment on the drafts, as per our normal WG process.

Andy

On Wed, Nov 2, 2016 at 12:33 PM, Ersue, Mehmet (Nokia - DE/Munich) <
[email-masked]> wrote:

> Hi Eric,
>
>
>
> a Design Team has a particular meaning at IETF. The members of an IETF DT
> are nominated by the AD and WG co-chairs.
>
> An IETF DT generally works as a closed group and comes up after a
> scheduled time period with a draft for WG review.
>
>
>
> Although the end result is similar the team you guys have set up is a group
> of volunteers discussing the notification drafts.
>
> I believe the Notification Team can be much more efficient based on the
> early comments and feedback they are asking the WG to provide.
>
>
>
> Mehmet
>
>
>
> *From:* Eric Voit (evoit) [mailto:[email-masked]]
> *Sent:* Wednesday, November 02, 2016 8:02 PM
> *To:* Ersue, Mehmet (Nokia - DE/Munich) <[email-masked]>;
> [email-masked]
> *Subject:* RE: [Netconf] Minutes 26-Oct: NETCONF/RESTCONF/HTTP2
> Subscription & Event drafts
>
>
>
> Thanks Mehmet, this makes sense.  We in the design team fully understand
> these meetings are simply intended to develop material ready for wider
> NETCONF socialization.  In fact we will be bringing a host of items for
> more formal discussion at IETF97.
>
>
>
> *From:* Ersue, Mehmet, November 2, 2016 1:41 PM
>
> Dear NETCONF WG,
>
>
>
> the co-chairs would like to thank Eric Voit and the notification team for
> their essential discussion and the valuable work they are doing.
>
>
>
> However we also would like to clarify that the reported meeting below is
> an adhoc-meeting of a group of volunteers and not an official WG virtual
> meeting.
>
> As such the agreements achieved in this meeting series are limited to the
> meeting attendees and don’t reflect WG consensus.
>
> As per IETF-process NETCONF WG maillist involving all WG members is the
> panel which will declare WG consensus based on the WG drafts the
> notification team is preparing.
>
>
>
> @All:
>
> Please comment on the discussion results of the notification team meeting
> on the maillist. Such early comments are a good contribution to WG
> consensus preparation.
>
> PS: Official WG virtual meetings are required to agree with the AD and
> need to be planned and announced by the co-chairs 1-2 weeks ahead of time.
>
> We made the experience in the past that finding the appropriate time for a
> WG virtual meeting is very difficult. An adhoc-meeting OTOH can be
> organized much more easily.
>
>
>
> Many Thanks,
>
> Mehmet & Mahesh
>
>
>
>
>
> *From:* Netconf [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Eric Voit (evoit)
> *Sent:* Wednesday, October 26, 2016 10:43 PM
> *To:* [email-masked]' <netconf-subscriptions-dt@
> voit.org>; [email-masked]
> *Subject:* [Netconf] Minutes 26-Oct: NETCONF/RESTCONF/HTTP2 Subscription
> & Event drafts
>
>
>
> *Meeting Materials*
> *Attending*
> WebEx Recording
> <https://cisco.webex.com/ciscosales/lsr.php?RCID=1c507c6625ac4e74bfc425e650dc978b>
>
> password: qAb6KumY
>
> Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar Nilsen-Nygaard, Eric
> Voit, Tim Jenkins, Balazs Lengyel, Kent Watsen, Ambika Tripathy
> ·         Alex, Eric, Alberto have updated model and draft. Look for
> latest shortly posted to IETF
>
> ·         Discussed on the call to still be mixed into the text.
> (upcoming update will include)
>
> ·         Reviewed Andy's proposal for a new filter type based on
> hierarchical event type metadata
>
> o    Seems like a good idea. The hard part will be defining the event
> hierarchy. That will play out in the IETF somewhat decoupled from
> subscriptions as it could be used for GET filter as well.
>
> ·         *Need for a new Draft* including Metadata filtering
>
> o    There is not an existing YANG filter for Metadata. Nor is there a
> filter for metadata + subtree filtering. This needs to be solved for GET
> operations (i.e., this is not just about subscriptions).
>
> ·         For populating the metadata: Subtrees will inherit the
> event-types of their parents, unless otherwise indicated via a deviations
> file.
>
> ·         For metadata filters, there needs to be some mechanism that the
> on-change notification for metadata pushed data in the sequential order of
> operations on a device. For example, you want to push object metadata
> changes for before you see the same object's corresponding changes for
> datastore.
>
> ·         Open question on filters: Are the capabilities in a filter type
> allowed to be mixed/matched to make a more complex union or intersection
> filter within a subscription?
>
> o    Eric recommendation: We don't allow application of multiple filters
> concurrently. Building a filter syntax for unions and intersections across
> filter types is interesting, but hard. Problematically it puts us in the
> business where we have to define what is possible (or not) via the
> combination of any two filter types. It would be simpler to leave the valid
> combinations of filter capabilities to any particular normative reference.
>
> ·         Streams
> o    Streams are optional, and will include NETCONF and custom-stream
> entries. We will not try to standardize any new IETF streams at this point.
>
> o    Metadata would allow filtering on OpState info (upcoming draft from
> the datastore design team). This would accomplish the same business
> objectives as what we were talking about previously with IETF standardized
> streams. Anyone who wants to meet those objectives prior to having a filter
> on OpState metadata can define their own custom-stream.
> ·         Einar believes real world examples necessitate that a Publisher
> be able to partition and sequence the push updates.
>
> ·         Belief that Anchor-time is not the right object to use for
> determining whether partial push updates are acceptable to be sent. Instead
> a new periodic type subscription object should be created. Perhaps
> "partial-push-accepted"?
>
> ·         Proposal to be brought to mailing list (by Einar?) as people
> are worried about the extra complexity this will introduce. Topics to
> address include:
>
> o    A push update for a subscription with the partial-push-accepted flag
> = yes is not assumed to be a complete representation of the datastore, it
> just contains that set of objects/values at that particular time of a push
> update.
>
> o    Can be used during negotiation if an internally consistent set of
> objects should not be assumed by the receiver.
>
> o    Push updates are accumulated across a known period established
> across a subscription, with the last value received being current. Object
> which is older than the period is assumed to be stale or deleted.
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>
>

---

From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
Date: Wed, 2 Nov 2016 19:57:01 +0000

Andy,

I believe such reports and asking for comments is very useful for the solid progress.

Mehmet

From: Andy Bierman [mailto:[email-masked]]
Sent: Wednesday, November 02, 2016 8:40 PM
To: Ersue, Mehmet (Nokia - DE/Munich) <[email-masked]>
Cc: Eric Voit (evoit) <[email-masked]>; [email-masked]
Subject: Re: [Netconf] Minutes 26-Oct: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts

Hi,

Perhaps it would be better if the ad-hoc group did not post any meeting minutes
to the WG.  There is no official content in them but they seem to be causing a problem anyway.
I suggest that no minutes be posted at all.  Just post the drafts and the WG
can comment on the drafts, as per our normal WG process.

Andy

On Wed, Nov 2, 2016 at 12:33 PM, Ersue, Mehmet (Nokia - DE/Munich) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

Mehmet

From: Eric Voit (evoit) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 02, 2016 8:02 PM
To: Ersue, Mehmet (Nokia - DE/Munich) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Netconf] Minutes 26-Oct: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts

Eric

However we also would like to clarify that the reported meeting below is an adhoc-meeting of a group of volunteers and not an official WG virtual meeting.
As such the agreements achieved in this meeting series are limited to the meeting attendees and don’t reflect WG consensus.
As per IETF-process NETCONF WG maillist involving all WG members is the panel which will declare WG consensus based on the WG drafts the notification team is preparing.

@All:

Many Thanks,
Mehmet & Mahesh

From: Netconf [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, October 26, 2016 10:43 PM
To: [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [Netconf] Minutes 26-Oct: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts

Meeting Materials

Attending

Modifications to Latest 5277bis
•         Alex, Eric, Alberto have updated model and draft. Look for latest shortly posted to IETF
o    Definitions updated throughout from 5277 for Publisher (from Event Server) and Subscriber (from Client)
o    Text simplifications/reductions
•         Discussed on the call to still be mixed into the text. (upcoming update will include)
o    Notifications: Remove added-to-subscription, and removed-from-subscription notifications.
o    Dynamic Subscriptions: don't allow modification to streams or encoding for modify-subscription RPC.
Filters and Streams
•         Reviewed Andy's proposal for a new filter type based on hierarchical event type metadata
o    Seems like a good idea. The hard part will be defining the event hierarchy. That will play out in the IETF somewhat decoupled from subscriptions as it could be used for GET filter as well.
•         Need for a new Draft including Metadata filtering
o    There is not an existing YANG filter for Metadata. Nor is there a filter for metadata + subtree filtering. This needs to be solved for GET operations (i.e., this is not just about subscriptions).
•         For populating the metadata: Subtrees will inherit the event-types of their parents, unless otherwise indicated via a deviations file.
•         For metadata filters, there needs to be some mechanism that the on-change notification for metadata pushed data in the sequential order of operations on a device. For example, you want to push object metadata changes for before you see the same object's corresponding changes for datastore.
•         Open question on filters: Are the capabilities in a filter type allowed to be mixed/matched to make a more complex union or intersection filter within a subscription?
o    Eric recommendation: We don't allow application of multiple filters concurrently. Building a filter syntax for unions and intersections across filter types is interesting, but hard. Problematically it puts us in the business where we have to define what is possible (or not) via the combination of any two filter types. It would be simpler to leave the valid combinations of filter capabilities to any particular normative reference.
o    We should advocate for a new IETF draft (above) which defines this.
•         Streams
o    Streams are optional, and will include NETCONF and custom-stream entries. We will not try to standardize any new IETF streams at this point.
o    Metadata would allow filtering on OpState info (upcoming draft from the datastore design team). This would accomplish the same business objectives as what we were talking about previously with IETF standardized streams. Anyone who wants to meet those objectives prior to having a filter on OpState metadata can define their own custom-stream.
Partial/incremental push of periodic data
•         Einar believes real world examples necessitate that a Publisher be able to partition and sequence the push updates.
o    This means no need to aggregate a single push from different linecards
o    Then able to load balance pushed for different objects with a different push timestamp.
•         Belief that Anchor-time is not the right object to use for determining whether partial push updates are acceptable to be sent. Instead a new periodic type subscription object should be created. Perhaps "partial-push-accepted"?
•         Proposal to be brought to mailing list (by Einar?) as people are worried about the extra complexity this will introduce. Topics to address include:
o    A push update for a subscription with the partial-push-accepted flag = yes is not assumed to be a complete representation of the datastore, it just contains that set of objects/values at that particular time of a push update.
o    Integrity across the datastore extract cannot be assumed.
o    Can be used during negotiation if an internally consistent set of objects should not be assumed by the receiver.
o    Push updates are accumulated across a known period established across a subscription, with the last value received being current. Object which is older than the period is assumed to be stale or deleted.
o    Establish proper meaning of updates-not-sent flag.

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 2 Nov 2016 20:10:14 +0000

Since they are useful, I will continue to send.   And maybe if we call ourselves the DezignTM Team, this won’t conflict with IETF keywords  ;-).

Eric

From: Ersue, Mehmet, November 2, 2016 3:57 PM

Andy,

Mehmet

From: Andy Bierman [mailto:[email-masked]]
Sent: Wednesday, November 02, 2016 8:40 PM
To: Ersue, Mehmet (Nokia - DE/Munich) <[email-masked]<mailto:[email-masked]>>
Cc: Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] Minutes 26-Oct: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts

Hi,

Andy

Mehmet

Eric

@All:

Many Thanks,
Mehmet & Mahesh

Meeting Materials

Attending

---

From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
Date: Wed, 2 Nov 2016 20:36:39 +0000

Sounds cool!

Cheers,
Mehmet

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: Wednesday, November 02, 2016 9:10 PM
To: Ersue, Mehmet (Nokia - DE/Munich) <[email-masked]>; Andy Bierman <[email-masked]>
Cc: [email-masked]
Subject: RE: [Netconf] Minutes 26-Oct: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts

Eric

Mehmet

Hi,

Andy

Mehmet

Eric

@All:

Many Thanks,
Mehmet & Mahesh

Meeting Materials

Attending

---

From: Benoit Claise <[email-masked]>
Date: Wed, 2 Nov 2016 23:19:09 +0100

> Since they are useful, I will continue to send.
>
Please do Eric.
Thanks for the positive attitude!

Regards, B.
>
> And maybe if we call ourselves the Dezign^TM Team, this won’t conflict 
> with IETF keywords  ;-).
>
> Eric
>
> *From:*Ersue, Mehmet, November 2, 2016 3:57 PM
>
> Andy,
>
> *From:*Andy Bierman [mailto:[email-masked]]
> *Sent:* Wednesday, November 02, 2016 8:40 PM
> *To:* Ersue, Mehmet (Nokia - DE/Munich) <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* Eric Voit (evoit) <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [Netconf] Minutes 26-Oct: NETCONF/RESTCONF/HTTP2 
> On Wed, Nov 2, 2016 at 12:33 PM, Ersue, Mehmet (Nokia - DE/Munich) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Eric,
>
>     a Design Team has a particular meaning at IETF. The members of an
>     IETF DT are nominated by the AD and WG co-chairs.
>
>     Although the end result is similar the team you guys have set up
>     is a group of volunteers discussing the notification drafts.
>
>     I believe the Notification Team can be much more efficient based
>     on the early comments and feedback they are asking the WG to provide.
>
>     Mehmet
>
>     *From:* Eric Voit (evoit) [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *To:* Ersue, Mehmet (Nokia - DE/Munich) <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>     Thanks Mehmet, this makes sense.  We in the design team fully
>     understand these meetings are simply intended to develop material
>     ready for wider NETCONF socialization.  In fact we will be
>     bringing a host of items for more formal discussion at IETF97.
>
>     the co-chairs would like to thank Eric Voit and the notification
>     team for their essential discussion and the valuable work they are
>     doing.
>
>     However we also would like to clarify that the reported meeting
>     below is an adhoc-meeting of a group of volunteers and not an
>     official WG virtual meeting.
>
>     As such the agreements achieved in this meeting series are limited
>     to the meeting attendees and don’t reflect WG consensus.
>
>     As per IETF-process NETCONF WG maillist involving all WG members
>     is the panel which will declare WG consensus based on the WG
>     drafts the notification team is preparing.
>
>     @All:
>
>     Please comment on the discussion results of the notification team
>     meeting on the maillist. Such early comments are a good
>     contribution to WG consensus preparation.
>
>     PS: Official WG virtual meetings are required to agree with the AD
>     and need to be planned and announced by the co-chairs 1-2 weeks
>     ahead of time.
>
>     We made the experience in the past that finding the appropriate
>     time for a WG virtual meeting is very difficult. An adhoc-meeting
>     OTOH can be organized much more easily.
>
>     Many Thanks,
>
>     Mehmet & Mahesh
>
>     *From:* Netconf [mailto:[email-masked]] *On Behalf Of
>     *Eric Voit (evoit)
>     *To:* [email-masked]
>     <mailto:[email-masked]>'
>     <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>     *Subject:* [Netconf] Minutes 26-Oct: NETCONF/RESTCONF/HTTP2
>     Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar
>     Nilsen-Nygaard, Eric Voit, Tim Jenkins, Balazs Lengyel, Kent
>     Watsen, Ambika Tripathy
>
>
>     ·Alex, Eric, Alberto have updated model and draft. Look for latest
>     shortly posted to IETF
>
>     oDefinitions updated throughout from 5277 for Publisher (from
>     Event Server) and Subscriber (from Client)
>
>     oText simplifications/reductions
>
>     ·Discussed on the call to still be mixed into the text. (upcoming
>     update will include)
>
>     oNotifications: Remove added-to-subscription, and
>     removed-from-subscription notifications.
>
>     oDynamic Subscriptions: don't allow modification to streams or
>     encoding for modify-subscription RPC.
>
>
>         Filters and Streams
>
>     ·Reviewed Andy's proposal for a new filter type based on
>     oSeems like a good idea. The hard part will be defining the event
>     ·*Need for a new Draft*including Metadata filtering
>
>     oThere is not an existing YANG filter for Metadata. Nor is there a
>     filter for metadata + subtree filtering. This needs to be solved
>     for GET operations (i.e., this is not just about subscriptions).
>
>     ·For populating the metadata: Subtrees will inherit the
>     event-types of their parents, unless otherwise indicated via a
>     deviations file.
>
>     ·For metadata filters, there needs to be some mechanism that the
>     on-change notification for metadata pushed data in the sequential
>     order of operations on a device. For example, you want to push
>     object metadata changes for before you see the same object's
>     corresponding changes for datastore.
>
>     ·Open question on filters: Are the capabilities in a filter type
>     allowed to be mixed/matched to make a more complex union or
>     intersection filter within a subscription?
>
>     oEric recommendation: We don't allow application of multiple
>     filters concurrently. Building a filter syntax for unions and
>     intersections across filter types is interesting, but hard.
>     Problematically it puts us in the business where we have to define
>     what is possible (or not) via the combination of any two filter
>     types. It would be simpler to leave the valid combinations of
>     filter capabilities to any particular normative reference.
>
>     oWe should advocate for a new IETF draft (above) which defines this.
>
>     ·Streams
>
>     oStreams are optional, and will include NETCONF and custom-stream
>     oMetadata would allow filtering on OpState info (upcoming draft
>     from the datastore design team). This would accomplish the same
>     business objectives as what we were talking about previously with
>     IETF standardized streams. Anyone who wants to meet those
>     objectives prior to having a filter on OpState metadata can define
>     their own custom-stream.
>
>
>     ·Einar believes real world examples necessitate that a Publisher
>     oThis means no need to aggregate a single push from different
>     linecards
>
>     oThen able to load balance pushed for different objects with a
>     different push timestamp.
>
>     ·Belief that Anchor-time is not the right object to use for
>     determining whether partial push updates are acceptable to be
>     sent. Instead a new periodic type subscription object should be
>     created. Perhaps "partial-push-accepted"?
>
>     ·Proposal to be brought to mailing list (by Einar?) as people are
>     worried about the extra complexity this will introduce. Topics to
>     address include:
>
>     oA push update for a subscription with the partial-push-accepted
>     flag = yes is not assumed to be a complete representation of the
>     datastore, it just contains that set of objects/values at that
>     particular time of a push update.
>
>     oIntegrity across the datastore extract cannot be assumed.
>
>     oCan be used during negotiation if an internally consistent set of
>     oPush updates are accumulated across a known period established
>     across a subscription, with the last value received being current.
>     Object which is older than the period is assumed to be stale or
>     deleted.
>
>     oEstablish proper meaning of updates-not-sent flag.
>
>
>     [email-masked] <mailto:[email-masked]>