Re: [Netconf] WGLC on restconf-notif-08

["Eric Voit (evoit)" <[e-mail]>]

> "Reshad Rahman (rrahman)" <[e-mail]> wrote:
> > Hi,
> >
> > On 2018-10-11, 3:41 AM, "Martin Bjorklund" <[e-mail]> wrote:
> >
> >     Hi,
> >
> >     Trimming to open issues:
> >
> >
> >     "Reshad Rahman (rrahman)" <[e-mail]> wrote:
> >     > Thanks for the review, inline.
> >     >
> >     > On 2018-10-10, 7:45 AM, "Netconf on behalf of Martin Bjorklund"
> <[e-mail] on behalf of [e-mail]> wrote:
> >     >
> >     >     Hi,
> >     >
> >     >     I think that this document needs some fixes before it is ready.  Here
> >     >     are my comments.
> >     >
> >     >
> >     >     o  Title and Abstract
> >     >
> >     >       This document is called:
> >     >
> >     >          RESTCONF Transport for Event Notifications
> >     >
> >     >       but netconf-notif called
> >     >
> >     >          NETCONF Support for Event Notifications
> >     >
> >     >       The titles should probably be aligned.
> >     > <RR> Ack.
> >     >
> >     >       ... and note the document that they support is called
> >     >
> >     >          Customized Subscriptions to a Publisher's Event Streams
> >     >
> >     >       It is not obvious that "RESTCONF Transport for Event
> >     >       Notifications" relates to "Customized Subscriptions to a Publisher's
> >     >       Event Streams".
> >     > <RR> So you're suggesting "RESTCONF Support for Customized
> Subscriptions to a Publisher's Event Streams" (and likewise for NETCONF)?
> >
> >     This seems a bit excessive.  Maybe  "XXXCONF Support for Customized
> >     Subscriptions to Event Notifications"
> > <RR2> Works for me.
> >
> >     Maybe even change the SN title to the simpler
> >
> >       "Customized Subscriptions to Event Notifications"
> > <RR2> Eric?

We are not subscribing to Event Notifications, we are subscribing to a publisher's Event Streams in SN.   I don't think the SN title should change.

> >     >     o  Section 3.4
> >     >
> >     >       The text says:
> >     >
> >     >        An HTTP GET is then sent on a separate logical connection (b) to the
> >     >        URI on the publisher.
> >     >
> >     >       I think that is also ok if the GET is sent on (a) - in the case that
> >     >       you don't care about being able to modify the subscription.  This
> >     >       should be clarified.
> >     >  <RR> Yes that also works, will add some text.
> >     >
> >     >       Also, "modify-subscription" may be sent on some other session.
> >     > <RR> As long as from same subscriber I assume. Do we care about NAT
> >     >     scenarios?
> >
> >     There is nothing in SN that says that modify-subscription must be from
> >     the same subscriber.
> >
> >     IMO the idea of restricting some rpcs to "the same transport session"
> >     is unnecessary, and obviously problematic.
> > <RR2> Problematic from an implementation view or from a functionality
> view? Would like to hear from others on this.
> >
> >     I think that the
> >     restriction should be removed from delete-subscription (and then
> >     remove kill-subscription, since it is the same as
> >     delete-subscription).
> >
> >     >     o  Section 4
> >     >
> >     >        o  take any existing subscription "dependency" and map the HTTP2
> >     >           stream for the parent subscription into the HTTP2 stream
> >     >           dependency.
> >     > <RR> Will do, dependency leaf in SN draft and section 5.3.1 of rfc7540.
> >     >       (same comments as above wrt. references)
> >     >
> >     >       This text seems to imply that there in fact exists a HTTP2 stream
> >     >       for the "parent subscription".  I don't think is necessarily true.
> >     > <RR>  So just clarify that this applies only when there's an HTTP2 stream
> for the parent subscription?
> >
> >     I have no clue.  Why is this copting going on?  Isn't the priority and
> >     dependency thing supposed to work for all types of transport?  If so,
> >     why copy down to HTTP/2?
> > <RR2> Stream dependency and priority are HTTP2 specific, so this explains
> how to map the subscription Qos properties to HTTP2 properties.
> 
> Are you saying that the "dependency" function in SN is not applicable to all
> transports?

Dependency and priority are applicable to other transports.   The mapping happens to be very straight-forward with HTTP2.

Eric

> /martin