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

[Martin Bjorklund <[e-mail]>]

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"

Maybe even change the SN title to the simpler

  "Customized Subscriptions to Event Notifications"

>     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.  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?



/martin