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

[Martin Bjorklund <[e-mail]>]

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