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

[Martin Bjorklund <[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?
>     
>     >     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?


/martin