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

["Reshad Rahman (rrahman)" <[e-mail]>]

Hi Kent,


On 2018-10-29, 2:29 PM, "Kent Watsen" <[e-mail]> 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.    
    
    > 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