Re: [Netconf] draft-ietf-netconf-rfc6536bis Query

[Martin Bjorklund <[e-mail]>]

Hi,

Rohit R Ranade <[e-mail]> wrote:
> Hi Martin,
> 
> Consider running data-store has below node.
                   ^^^^^^^^^^^^^^^^^^^^^^^^^
> /top/interface[name="Ethernet0/0"]/mtu 
> 
> In the above case, "mtu" is a data-store node , because it is part of
> a running data-store ?

Yes.

> And if I just have a path as /top/interface/mtu ==> Here mtu is just a
> "data node" ?

A path by itself can't tell you what kind of node it points to.  If
this is a path into the schema, and mtu is a leaf, then it is a data
node.  If mtu had been a 'choice' it wouldn't be a data node.

> The reason why I am asking these points is that RFC 6536 mentions that
> data-store nodes should not be shown in rpc-error. But we want to
> output in error-message something like "access is denied for
> /top/interface/mtu" to give a meaningful error-message. Whether such
  ^^^^^^^^^^^^^^^^^^

I assume you mean: /top/interface[name="Ethernet0/0"]/mtu ?

> an error-message makes the server non-compliant ?

If the user doesn't have access to "Ethernet0/0" at all, you might
reveal the fact that this interface exists if you send this
error-path.

In general it is safer to just send 'access-denied' and no additional
info.


/martin


> With Regards,
> Rohit R
> 
> -----Original Message-----
> From: Martin Bjorklund [mailto:[e-mail]] 
> Sent: 05 February 2018 14:20
> To: Rohit R Ranade <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis Query
> 
> Hi,
> 
> Rohit R Ranade <[e-mail]> wrote:
> > Hi Martin,
> > 
> > There are around 6-7 places in the BIS and RFC 6536 where the term "
> > datastore node" is used. It is unclear what is the meaning of this 
> > term as it is not defined in the Terminology section and it is unclear
> > what is the difference between this term and "data node". Please 
> > clarify
> 
> Is the term "datastore node" really unclear?  Would a defintion "a
> node in a datastore" help (I think it would be a tautology).
> 
> The term "data node" is imported from RFC 7950.
> 
> 
> /martin
> 
> 
> > For example: In section 3.2.3
> > 
> >    The contents of specific restricted datastore nodes MUST NOT be
> >    exposed in any <rpc-error> elements within the reply.
> > 
> > 
> > With Regards,
> > Rohit R
> > 
> > -----Original Message-----
> > From: Rohit R Ranade
> > Sent: 02 February 2018 15:19
> > To: 'Martin Bjorklund' <[e-mail]>
> > Subject: RE: [Netconf] draft-ietf-netconf-rfc6536bis Query
> > 
> > Ok. 
> > 
> > With Regards,
> > Rohit R
> > 
> > -----Original Message-----
> > From: Martin Bjorklund [mailto:[e-mail]]
> > Sent: 02 February 2018 15:17
> > To: Rohit R Ranade <[e-mail]>
> > Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis Query
> > 
> > Hi,
> > 
> > Rohit R Ranade <[e-mail]> wrote:
> > > Hi Martin,
> > > 
> > > Should we not be specific in the DRAFT about how to handle 
> > > <create-subscription> rpc like we have done for the replay control 
> > > notifications ?
> > 
> > The control notifications are treated differently b/c they are control
> > notifications, not b/c they are not defined in a YANG module.
> > 
> > I think you have a valid point; however, since the WG is currently 
> > defining new operations that will replace the old 
> > <create-subscription>, I think this problem will go away.
> > 
> > Also, 6536bis is in the RFC editor queue, so changing in 6536bis this 
> > is quite problematic.
> > 
> > 
> > /martin
> > 
> > 
> > > Else each device will have its own mechanism of access control for 
> > > <create-subscription>.
> > > 
> > > With Regards,
> > > Rohit R
> > > 
> > > -----Original Message-----
> > > From: Martin Bjorklund [mailto:[e-mail]]
> > > Sent: 01 February 2018 19:05
> > > To: Rohit R Ranade <[e-mail]>
> > > Cc: [e-mail]
> > > Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis Query
> > > 
> > > Hi,
> > > 
> > > Rohit R Ranade <[e-mail]> wrote:
> > > > Hi All,
> > > > 
> > > > Q1:
> > > > In the notification authorization Section 3.4.6 there is mention 
> > > > that REPLAY notifications should be allowed by default.
> > > 
> > > I think you mean <replay-complete>.   Replayed notifications in
> > > general are not allowed by default.
> > > 
> > > > But there is no mention of how to handle <create-subscription> 
> > > > operation authorization which can trigger these Replay notifications ?
> > > > Since there is no module defined for it, there is no way to add a 
> > > > rule for permitting or denying it.
> > > > 
> > > > 
> > > > 1.  How do the current NACM implementations handle it ? Allow 
> > > > <create-subscription> if exec-default is PERMIT ? or always allow 
> > > > <create-subscription> ?
> > > 
> > > I had to check, and our implementation matches create-subscription 
> > > if the module-name in the rule is "*".
> > > 
> > > I think some implementations use an internal (non-standard) YANG 
> > > module name for the model in RFC 5277, so they presumably match if 
> > > that internal module name is given, or "*".
> > > 
> > > > Q2: If there is an error of access-denied for edit-config 
> > > > operation, does the RFC restrict from outputting the <error-path> 
> > > > of the data-store node for such operations ?
> > > > Section 3.2.5 has " The contents of specific restricted datastore 
> > > > nodes MUST NOT be
> > > > 
> > > >    exposed in any <rpc-error> elements within the reply." , what is the
> > > >    meaning of 'content' here ? the schema-name of the leaf / key-values
> > > >    of data-store-nodes ?
> > > > 
> > > > Since the user has inputted the keys for the data-store nodes is 
> > > > there any security risk in giving back the values to the user ?
> > > 
> > > 3.4.3 also has
> > > 
> > >    A server MUST NOT include any information the client is not allowed
> > >    to read in any <error-info> elements within the <rpc-error> response.
> > > 
> > > 
> > > /martin
> > > 
> > 
>