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

[Alexander Clemm <[e-mail]>]

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:[e-mail]] On Behalf Of Mahesh Jethanandani
Sent: Wednesday, May 03, 2017 2:18 PM
To: Netconf <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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