Subject: [Netconf] I-D Action: draft-ietf-netconf-subscribed-notifications-14.txt

From: [email-masked]
Date: Mon, 02 Jul 2018 15:47:35 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : Customized Subscriptions to a Publisher's Event Streams
        Authors         : Eric Voit
                          Alexander Clemm
                          Alberto Gonzalez Prieto
                          Einar Nilsen-Nygaard
                          Ambika Prasad Tripathy
	Filename        : draft-ietf-netconf-subscribed-notifications-14.txt
	Pages           : 74
	Date            : 2018-07-02

Abstract:
   This document defines a YANG data model and associated mechanisms
   enabling subscriber-specific subscriptions to a publisher's event
   streams.  Applying these elements allows a subscriber to request for
   and receive a continuous, custom feed of publisher generated
   information.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-14
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-subscribed-notifications-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-subscribed-notifications-14

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Kent Watsen <[email-masked]>
Date: Thu, 5 Jul 2018 16:22:31 +0000

Looking at the diffs I see:

     Note that each individual receiver is identifiable by	
     its "name".  This "name" plus the "transport" are used by a	
     publisher implementation to a parameters needed to establish and	
     maintain a network connection using that transport.

I know that you worked this out with Martin, but I think that for configured 
subscriptions (and that's all we're talking about here, right?), a leafref to
the actual transport instance (e.g., /restconf-server/call-home/restconf-client)
would be more exact.

Kent

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

Abstract:

<mangled-url-snipped/>

<mangled-url-snipped/>

<mangled-url-snipped/>

<mangled-url-snipped/>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 5 Jul 2018 17:36:48 +0000

> From: Kent Watsen, July 5, 2018 12:23 PM
> 
> subscriptions (and that's all we're talking about here, right?), a leafref to the
> actual transport instance (e.g., /restconf-server/call-home/restconf-client)
> would be more exact.

Yes, just configured subscriptions.  As some transports might not want/need call home, adding the leafref should be defined in each transport draft.  

So how about text which says: "Note that each individual receiver is identifiable by its "name".  Via this "name", publisher transport parameters can be referenced in order to establish and maintain a transport connection with a receiver.  This transport specific reference can come in several forms, including the augmentation of leafrefs to an actual transport instance.  Such augmentations would be defined in transport specific specifications building upon this document."

Eric

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

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 07 Jul 2018 12:21:53 +0200 (CEST)

"Eric Voit \(evoit\)" <evoit=[email-masked]> wrote:
> > actual transport instance (e.g.,
> > /restconf-server/call-home/restconf-client)
> > would be more exact.
> 
> Yes, just configured subscriptions.  As some transports might not
> want/need call home, adding the leafref should be defined in each
> transport draft.

Agree, and as you point out below, it doesn't have to be a leafref to
something, it could also be done inline.  This is entirely up to the
transport mapping document.

> So how about text which says: "Note that each individual receiver is
> identifiable by its "name".  Via this "name", publisher transport
> parameters can be referenced in order to establish and maintain a
             ^^^^^^^^^^^^^^^^^

Maybe "can be defined"  or even "must be defined".

> transport connection with a receiver.  This transport specific
> reference can come in several forms, including the augmentation of
> leafrefs to an actual transport instance.  Such augmentations would be
                                                                ^^^^^^^^

must be?

> defined in transport specific specifications building upon this
> document."

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Sat, 7 Jul 2018 14:17:48 +0000

Hi Martin,

> From: Martin Bjorklund, July 7, 2018 6:22 AM
> 
> > > I know that you worked this out with Martin, but I think that for
> > > configured subscriptions (and that's all we're talking about here,
> > > right?), a leafref to the actual transport instance (e.g.,
> something, it could also be done inline.  This is entirely up to the transport
> mapping document.
> 

Now: "must be defined"
 
> > leafrefs to an actual transport instance.  Such augmentations would be

Now: "must be"

Eric

> > > Please note that it may take a couple of minutes from the time of
> > > submission until the htmlized version and diff are available at
> > > tools.ietf.org.
> > >