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

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

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

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
>