Re: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis

Hi,

I am strongly opposed to datastore-specific access control.
I need to see a use-case that demonstrates why a particular client
needs to be denied access to a specific subtree in 1 datastore vs. another
datastore.

The NACM procedures need to be mapped to protocol operations.
It is easier to do this for actual protocols than a generic placeholder.
It may be possible.

I do not agree NACM controls the internal access.
That is an implementation detail. NACM is enforced on clients using
NETCONF of RESTCONF.

If the WG wants the NACM procedures mapping to protocols to be more generic,
I could work on some proposed text to do that.

Andy

On Thu, May 4, 2017 at 10:22 AM, Alexander Clemm <alexander.clemm@huawei.com
> wrote:

> Hi,
>
>
>
> FWIW, I do have a few comments.  Overall the document is in good shape,
> but there are a few items where I think it can be made even better:-)
>
>
>
> -          I think it would be good to include a section on how the
> revised datastores will impact requirements on NACM.  I don’t think
> anything major is required, but there are a few places where some updates
> could be made, and/or perhaps a brief section could be added somewhere
> discussing this.  For example, in Figure 1 (Section 2.1) where it says
> “datastore or state data access” (technically, this remains correct, but
> this seems to have the previous model in mind), also fig 3 assuming RPCs
> will always be against config datastore).   It might also mention which
> datastore NACM rules apply to when the same data is contained in multiple
> datastores.  Technically, I don’t think there will be a distinction (any
> differentiation would apply to read operations, and I cannot think of a
> good example where such differentiation would be needed), still it might be
> good to be explicit about it.
>
> -          In section 3.4.6 (outgoing <notification> authorization), it
> states that access control is applied only to notification as a whole, not
> to any data it contains.  This is clear enough; however, it is a
> limitation.  Specifically, in YANG-Push there is a requirement to be able
> to apply a security filter to not push data that the receiver is not
> authorized to receive (or not accept/terminate a subscription which
> contains such data altogether).  If NACM does not provide this, another
> mechanism or a NACM extension will be needed (that will still need to use
> the privileges configured in NACM).  At a minimum, this needs to be clearly
> called out.
>
> -          I wonder why NACM is restricted to NETCONF or RESTCONF.
> Really, this restricts access to data in YANG datastores; while NETCONF and
> RESTCONF do need to be called out specifically and the document does need
> to spell out how it is applied in this context, it would probably be good
> to clarify that NACM should apply to other protocol access.
>
> -          It would be good to indicate that the source of access control
> rules is not restricted to external clients, but that they could originate
> from the server itself.  This is the same config/operational state
> discussion that has come up in other contexts (e.g. the topology models),
> and I think it applies here as well.  Again, this is where the revised
> datastores model is intended to provide a solution – i.e. the NACM rules in
> the config datastore may be only a subset of the ones in the operational
> datastore, etc – but I think it is important enough to be called.
>
>
>
> Thanks
>
> --- Alex
>
>
>
> *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Mahesh
> Jethanandani
> *Sent:* Wednesday, May 03, 2017 2:18 PM
> *To:* Netconf <netconf@ietf.org>
> *Subject:* Re: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis
>
>
>
> Folks,
>
>
>
> There has been literally no feedback on this document, either to say they
> have read the document and support it, or to express concerns about the
> document. Silence, unfortunately is not a good guide for us. To move the
> document forward, we need to hear from folks, including those who were in
> IETF 98.
>
>
>
> Thanks.
>
>
>
> On Apr 18, 2017, at 5:34 PM, Mahesh Jethanandani <mjethanandani@gmail.com>
> wrote:
>
>
>
> NETCONF WG,
>
> In IETF 98, the authors indicated that the above draft was ready for Last
> Call, and the consensus in the room indicated as much.
>
>
>
> This is a start of a 2 week WG Last Call for
> draft-ietf-netconf-rfc6536bis. After two weeks, the document will be
> assigned a shepherd, and the document will be prepared for IESG.
>
> The latest version of the draft can be found at:
> https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-01
>
> Please review and send any comments to the WG mailing list or by
> responding to this e-mail. Comments can be statements such as, I
> read/reviewed the document and believe it is ready for publication, or I
> have concerns about the document. For the latter, please indicate what your
> concerns are.
>
> Any reports on implementation status or plans to implement are also very
> useful.
>
>
>
> Authors, please indicate if you are aware of any IPRs related to the draft.
>
>
>
> Thanks.
>
> Mahesh and Mehmet
>
>
>
>
>
>
>
> Mahesh & Mehmet
>
>
>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>