Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-notif-09.txt

Kent/Martin, for 2) do you want additional text in the -notif drafts or is the SN text below enough?

Regards,
Reshad.

On 2018-10-30, 7:30 AM, "Eric Voit (evoit)" <evoit@cisco.com> wrote:

    > -----Original Message-----
    > From: Netconf <netconf-bounces@ietf.org> On Behalf Of Reshad Rahman
    > (rrahman)
    > Sent: Monday, October 29, 2018 6:01 PM
    > To: Kent Watsen <kwatsen@juniper.net>; netconf@ietf.org
    > Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-notif-09.txt
    > 
    > Hi Kent,
    > 
    > 
    > On 2018-10-29, 2:29 PM, "Kent Watsen" <kwatsen@juniper.net> wrote:
    > 
    >     Hi Reshad,
    > 
    >     > Most of the comments received during WGLC (from Kent, Martin and
    >     > Qin) have been addressed. Those not addressed are:
    >     >
    >     > 1- s/uri/location/ (to use same term as in RFC8040), I'm fine with
    >     >   this change but would like to hear from WG.
    > 
    > 
    >     I resist the idea that node names need to be consistent across modules.
    >     Yes, there exists some meta-conventions (e.g., the "enabled" leaf) that
    >     are unfortunately with us at the moment.
    > 
    >     Modules should firstly use whatever name makes most sense for their
    >     own purpose.  If it doesn't matter, then picking a value consistent
    >     with another module is okay, but I wouldn't spend more than five
    >     minutes searching for it.
    > 
    >     FWIW, the zerotouch draft has an inet:uri node called "download-uri".
    >     I don't know if it's a better name within the ZTP context, but it
    >     made sense to me at the time and no one questioned it.
    > <RR> I'll keep "uri" unless we hear from more people who would like to see it
    > changed to location.   I don't feel strongly about this, I got used to "uri" and
    > think it's appropriate.
    > 
    >     > 2- Allowing modify/delete subscription from a different connection. There
    >     >  was a discussion between Martin and Eric on this topic:
    >     >
    > https://mailarchive.ietf.org/arch/msg/netconf/3WaiWBVlLhj9wBOtuFuxVJkfsig
    > 
    >     RESTCONF doesn't have connections, per se, but sometimes drafts refer to
    >     the underlying TLS connection.
    > 
    >     Regardless, the general goals (for NETCONF too, I would think) could be:
    >       - a client (i.e., a RESTCONF username) can always modify/delete/resynch
    >         their own subscriptions.
    >       - an authorized administrator can modify/kill any client's subscription.
    > <RR> We should have this discussion in the context of SN.

    This is covered in SN.  Section 2.4.3:

    "Dynamic subscriptions can only be modified via this RPC using a transport session connecting to the subscriber."

    and Section 2.4.4:

    " Dynamic subscriptions can only be deleted via this RPC using a transport session connecting to the subscriber."

    In  -v19, I have also removed the sentence: " If the delete request
       matches a known subscription established on the same transport
       session, then it MUST be deleted; otherwise it MUST be rejected with
       no changes to the publisher."

    Eric

    >     > 3- Take uri out of subscription-modified. It was pointed out to me that
    >     > SN draft says the following:
    >     >
    >     >       For completeness, this subscription state change notification
    >     >       includes both modified and non-modified aspects of a subscription.
    > 
    >     I'm unsure how the [non-]modified matters to this question, but it seems
    >     that "uri" may not be *needed* as there is already an "id" node that
    >     achieves the similar ability to identify the subscription.  That said,
    >     I'm okay with the "uri" field being present, even if it's only mildly
    >     helpful, so long as there is no concern for the message size or the
    >     publisher's ability to populate the value.
    > <RR> The "uri" does not change, that's why the [non-]modified question came
    > up. I'm keeping it.
    > 
    > Regards,
    > Reshad.
    > 
    >     Kent // contributor
    > 
    > 
    > 
    > 
    > 
    > _______________________________________________
    > Netconf mailing list
    > Netconf@ietf.org
    > https://www.ietf.org/mailman/listinfo/netconf