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

Hi,

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.

I agree.  In this case I would have used the existing name, instead of
inventing a new name.

Not important though.

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

I agree that tying it to the username (RESTCONF or NETCONF or others)
makes sense.  But note that this can be done with NACM rules.  It
doesn't have to be built into the spec.  The details should go into the
SN draft.

/martin

> > 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.
> 
> 
> Kent // contributor
> 
> 
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 