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

Hi Andy,
That will work for me
Thanks
--- Alex

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Thursday, May 04, 2017 11:29 AM
To: Alexander Clemm <alexander.clemm@huawei.com>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>; Netconf <netconf@ietf.org>
Subject: Re: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis

On Thu, May 4, 2017 at 11:21 AM, Alexander Clemm <alexander.clemm@huawei.com<mailto:alexander.clemm@huawei.com>> wrote:
As mentioned in my message, I don’t think specific access control will be needed (I am not aware of specific use cases), but specifically with the revised datastore architecture about to the be introduced, its impact or nonimpact and interrelation with NACM should be discussed.  This can be as simple as a small paragraph or subsection “Revised Datastore Considerations”.

there is no text about candidate vs. running vs. startup.
The NACM rules apply to all of them the same.
I could add text that says there is no consideration for specific datastores.
Most rules apply to the schema tree. Data rules apply to instance data
but they apply to all instances in all datastores).  I can make this clear
in the next revision

Andy

I also do think that clarification regarding Netconf/Restconf vs other protocols is in fact needed.  I do think that NACM rules _should_ in fact be applicable.  Again, at a minimum something needs to be stated along those lines.  Otherwise you cannot introduce another transport without facing the choice between needing yet-another access control mechanism that may require redundant and potentially inconsistent configuration by administrators, or leaving out a big backdoor that would render NACM irrelevant.

--- Alex

From: Andy Bierman [mailto:andy@yumaworks.com<mailto:andy@yumaworks.com>]
Sent: Thursday, May 04, 2017 10:40 AM
To: Alexander Clemm <alexander.clemm@huawei.com<mailto:alexander.clemm@huawei.com>>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>; Netconf <netconf@ietf.org<mailto:netconf@ietf.org>>
Subject: 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<mailto: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<mailto:netconf-bounces@ietf.org>] On Behalf Of Mahesh Jethanandani
Sent: Wednesday, May 03, 2017 2:18 PM
To: Netconf <netconf@ietf.org<mailto: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<mailto: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<mailto:Netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf