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

[Rohit R Ranade <[e-mail]>]

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 ?

And if I just have a path as /top/interface/mtu ==> Here mtu is just 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 an error-message makes the server non-compliant ?

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