Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure

From: "Zhengguangying (Walker)" <[email-masked]>
Date: Mon, 6 Feb 2017 03:52:23 +0000

+1 on (b) and (c) as separate documents (and hence a more modular document structure), for the reasons stated by Eric.  
--- Walker

路在脚下，Walker

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 2017年2月4日 4:00
To: [email-masked]
Subject: Netconf Digest, Vol 108, Issue 6

Send Netconf mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/netconf
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Netconf digest..."

Today's Topics:

   1. Re: New Notification and Subscription Features WASFW: 3
      Options for Subscription & Event Notification draft structure
      (Alexander Clemm)
   2. Re: New Notification and Subscription Features WASFW: 3
      Options for Subscription & Event Notification draft structure
      (t.petch)

----------------------------------------------------------------------

Message: 1
Date: Fri, 3 Feb 2017 02:42:26 +0000
From: Alexander Clemm <[email-masked]>
To: "Eric Voit (evoit)" <[email-masked]>, Mehmet Ersue
	<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Netconf] New Notification and Subscription Features
	WASFW: 3 Options for Subscription & Event Notification draft structure
Message-ID:
	<[email-masked]>
	
Content-Type: text/plain; charset="us-ascii"

+1 on (b) and (c) as separate documents (and hence a more modular document structure), for the reasons stated by Eric.  
--- Alex

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Thursday, February 02, 2017 2:25 PM
To: Mehmet Ersue <[email-masked]>; [email-masked]
Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure

> From: Netconf, January 31, 2017 5:18 PM
> 
> Thanks. It should read:
> 
> @All: Please comment on the documents a)-d) below. Especially on the
> questions:
> - whether the XML notification encoding section should be removed from
> 7950 and put into NETCONF WG documents as well as

I don't see a need to touch 7950 at this time.  I do see a reason for a new notification draft which can support headers.  We should define that new notification in a separate draft, and collapse it into YANG 1.2 whenever there is sufficient business need.

> - whether the documents b) and c) are good to separate or the 
> protocol-specific content should be put into 6241bis and RESTCONF-bis documents.

I would rather see (b) and (c) as separate documents.

For (b) benefits of separation include:
- security considerations and configuration for subscriptions
- considerations for parallel support / implementation compatibility with RFC-5277
- room for examples

In (c), the benefits of separation include:
- specifics of call-home and heartbeat for subscriptions
- security considerations and configuration for subscriptions
- benefits of HTTP2 for notifications (e.g., avoiding SSE), and HTTP2 Posts' interplay with GRPC.
- room for examples
it would be confusing to put all the above into Restconf.  And the ink on Restconf isn't dry yet.

> Mehmet
> 
> -----Original Message-----
> From: Juergen Schoenwaelder
> [mailto:[email-masked]]
> Sent: Tuesday, January 31, 2017 10:16 PM
> To: Mehmet Ersue <[email-masked]>
> Cc: 'Martin Bjorklund' <[email-masked]>; [email-masked]
> Subject: Re: [Netconf] New Notification and Subscription Features
> WASFW: 3 Options for Subscription & Event Notification draft structure
> 
> On Tue, Jan 31, 2017 at 10:01:02PM +0100, Mehmet Ersue wrote:
> > The original document set proposed was:
> >
> > a) A document which defines the protocol-neutral notification 
> > framework, i.e., explains the concepts of subscriptions, filters, 
> > control plane notifications, replay, etc.  And also defines the 
> > associated YANG data model, RPCs, etc. This is currently covered in 
> > 5277bis document which would need to be renamed.

How about renaming to: "subscribed-notifications"

> > b) A document which defines how notifications are sent over NETCONF 
> > (generalizing section 3.7 of RFC 5277) and how YANG notifications 
> > are encoded in XML and JSON 
> > (draft-ietf-netconf-netconf-event-notifications),
> >
> > c) A document which defines how notifications are sent over RESTCONF 
> > (generalizing section 6 of RESTCONF RFC) and HTTP2.  Also defines 
> > how YANG notifications are encoded in XML and JSON
> > (draft-ietf-netconf-restconf-notif)
> >
> > d) A document which defines the subscription and push mechanism for 
> > YANG datastores allowing subscriber applications to request updates 
> > from a YANG datastore (draft-ietf-netconf-yang-push).
> >
> >
> > This proposal was aiming to address the requirements Mahesh and I 
> > have read on NETCONF and NETMOD maillists and discussed with Eric:
> >
> > - Provide the protocol-neutral notification framework in a separate 
> > document.

Yes, I support a new protocol neutral notification draft which can support headers.

> > - Improve YANG specification RFC 7950 to be (as good as possible and
> > required) protocol-independent and remove XML and JSON notification 
> > encoding sections for NETCONF. This was also the discussion result 
> > between NETCONF and NETMOD co-chairs.

This is a good idea, but not urgent to me.

> > - Provide protocol-specific details e.g. how notifications are sent 
> > and the notification encodings in separate documents. This part 
> > could be for sure put into 6241bis and RESTCONF-bis. Though Eric and 
> > the co-chairs were favoring to have separate documents.

Yes, these would be the (b) and (c) documents.

Eric

> >
> > That said I see Martin's comments below as valid.
> >
> > > > I think this is fine, but *if* this happens to coincide with a
> > rfc6241bis document, I would be nice to move the contents of the 
> > second of these documents (i.e.,
> >
> > > > how notifications are sent over NETCONF) into rfc6241bis.  As 
> > > > has been
> > stated before, bumping the protocol version to 1.2 would allow us to 
> > change the
> >
> > > > "notification" element contents.
> >
> >
> >
> > @All: Please comment on the documents a)-d) above. Especially on the
> > questions:
> >
> > - whether the XML and JSON notification encoding sections should be 
> > removed from 7950 and put into NETCONF WG documents as well as
> >
> > - whether the documents b) and c) are good to separate or they 
> > should be put into 6241bis and RESTCONF-bis documents.
> >
> 
> Since when has RFC 7950 JSON notification encoding sections? This 
> email is confusing on multiple ends.
> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

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

------------------------------

Message: 2
Date: Fri, 3 Feb 2017 12:24:42 +0000
From: t.petch <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>,
	Mehmet Ersue <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] New Notification and Subscription Features
	WASFW: 3 Options for Subscription & Event Notification draft structure
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
Sent: Wednesday, February 01, 2017 11:30 AM

> On Wed, Feb 01, 2017 at 12:20:00PM +0100, Mehmet Ersue wrote:
> > Hi Kent,
> >
> > I believe the terms defined in 6241 are needed in the context of the
network configuration framework.
> > I think it is perfectly fine if 7950bis uses terms defined in 6241.
> > We don't need to redefine or duplicate these terms in another draft.
>
> We need to move towards a real architecture document that defines 
> overarching concepts and this architecture document should also 
> include the definintion of the core terminology we use.

Yes, I think that this has been a need for quite a while now.  I would see datastores as key to it and that means, for me, that it would to some extent cut the ground from underneath YANG, RESTCONF, NETCONF,  ...
so while it is not 7950bis or 6241bis or ...it would be standards track and would update many of the current documents.  Informational would, for me, be pointless.

What I struggle with, always have, is having a single set of concepts that spans, datastore, RPC, Notifications etc.  I have seen the much discussed s.6.4 of RFC7960 and its predecessors as a symptom of this, and likewise the often referred-to question of where is state data vis-a-vis datastores.

It may be that there cannot be a single set of concepts, that the architecture of an RPC has nothing meaningful in common with the architecture of 'running', even if they share a DDL, but we should try.

Whether this belongs on the Netconf list or the Netmod list or another list, I am less clear.

Tom Petch

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

------------------------------

Subject: Digest Footer

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

------------------------------

End of Netconf Digest, Vol 108, Issue 6
***************************************