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

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 3 May 2017 14:18:12 -0700

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 <[email-masked]> 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 <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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 3 May 2017 15:27:38 -0700

Hi.

I do not agree that there has been no feedback on this document.
The draft has not changed much since the early revisions.
There were comments on those revisions and refinements were made
to improve the text.

This update provides explicit support for RESTCONF and new YANG 1.1
constructs.
I think there has been sufficient feedback that these enhancements have
been adequately addressed.

Andy

On Wed, May 3, 2017 at 2:18 PM, Mahesh Jethanandani <[email-masked]
> wrote:

> 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.
>
> 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.
>
> 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.
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 4 May 2017 01:15:26 +0000

Hi Andy,
Hi Martin,

This is an excellent document.  I  have a few questions:

#1 Section 3.1.3
If a data node identified in a request has no read access allowed (i.e., data node rule violation), isn't it better to treat the response like the node didn't exist, i.e. a "data-missing" error code?   You highlight this as an issue in 3.7.2, but I don't see a reason why "data missing" isn't preferable to "access denied" (other than ease of debug.)

#2  Section 3.1.3
On the sentence: "If the user is not authorized to read all the specified data nodes and the notification node, then the notification is dropped for that subscription."    There is a difference between events (where the whole event should be discarded), and YANG object selections (where it is preferable to just discard those node for which a receiver has no access).   What are your thoughts based on the type of notification of allowing the simple dropping any nodes where read access is not available if the notification includes some extract of a yang datastore?

#3 Section 3.4.6
Outgoing <notification> Authorization in 3.4.6 say descendent nodes are out of scope.  But as some notifications can contain datastore extracts, it would seem useful allow NACM to act similarly to the processing of a response to a get.  Also is there an intersection of this point with #2 above?

Thanks,
Eric

From: Mahesh Jethanandani, May 3, 2017 5:18 PM

Folks,

Thanks.

On Apr 18, 2017, at 5:34 PM, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:

NETCONF WG,

Thanks.

Mahesh and Mehmet

Mahesh & Mehmet

---

From: Andy Bierman <[email-masked]>
Date: Wed, 3 May 2017 21:50:39 -0700

On Wed, May 3, 2017 at 6:15 PM, Eric Voit (evoit) <[email-masked]> wrote:

> If a data node identified in a request has no read access allowed (i.e.,
> data node rule violation), isn’t it better to treat the response like the
> node didn’t exist, i.e. a “data-missing” error code?   You highlight this
> as an issue in 3.7.2, but I don’t see a reason why “data missing” isn’t
> preferable to “access denied” (other than ease of debug.)
>
>
>

data-missing seems tied to the delete operation error
(client tried to delete a node that does not exist).
access-denied can apply to the object -- the data may or may not exist.
I think many of the NETCONF error-tags overlap and we just have to make
a subjective choice.

> #2  Section 3.1.3
>
> On the sentence: “If the user is not authorized to read all the specified
> data nodes and the notification node, then the notification is dropped for
> that subscription.”    There is a difference between events (where the
> whole event should be discarded), and YANG object selections (where it is
> preferable to just discard those node for which a receiver has no
> access).   What are your thoughts based on the type of notification of
> allowing the simple dropping any nodes where read access is not available
> if the notification includes some extract of a yang datastore?
>

The initial intent was to keep NACM simple and make it easier to have high
performance implementations.
NACM only allows the event-type to be tested, not any data within it. IMO
the new notification work will
be significantly more expensive to implement high performance notification
delivery.

NACM does not really work the way YANG push wants it to work.
The  path /my-event/interfaces/interface/name is not the same node
as /interfaces/interface/name. Some handwaving text may say treat these
nodes the same, but they are not related at all (from a NACM POV)

>
> #3 Section 3.4.6
>
> Outgoing <notification> Authorization in 3.4.6 say descendent nodes are
> out of scope.  But as some notifications can contain datastore extracts, it
> would seem useful allow NACM to act similarly to the processing of a
> response to a get.  Also is there an intersection of this point with #2
> above?
>

IMO this should not be done (unless you want you code to run way slower)
It also means the client cannot be sure what the server will leak.
I prefer to apply NACM at subscription-time. If the client is not allowed to
read everything in the requested subscription, it is denied.

This doesn't really work for data rules on specific instances that get
created
after the subscription starts. But applying NACM data rules to every
descendant
node in a YANG push is going to be extremely slow. This gets even worse
for subscriptions with multiple receivers (as NACM has to be enforced for
each receiver). I would prefer to see a solution that forces YANG push
to enforce NACM at update generation time (before the notification
delivery system ever sees it) But this assumes YANG push is aware
of the active subscriptions, so not an ideal solution at all.

Andy

>
>
> *From:* Mahesh Jethanandani, May 3, 2017 5:18 PM
>
> Folks,
>
>
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 4 May 2017 14:53:49 +0000

From: Andy Bierman, May 4, 2017 12:51 AM

On Wed, May 3, 2017 at 6:15 PM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,
Hi Martin,

#1 Section 3.1.3
If a data node identified in a request has no read access allowed (i.e., data node rule violation), isn’t it better to treat the response like the node didn’t exist, i.e. a “data-missing” error code?   You highlight this as an issue in 3.7.2, but I don’t see a reason why “data missing” isn’t preferable to “access denied” (other than ease of debug.)

<Eric> ok

#2  Section 3.1.3
On the sentence: “If the user is not authorized to read all the specified data nodes and the notification node, then the notification is dropped for that subscription.”    There is a difference between events (where the whole event should be discarded), and YANG object selections (where it is preferable to just discard those node for which a receiver has no access).   What are your thoughts based on the type of notification of allowing the simple dropping any nodes where read access is not available if the notification includes some extract of a yang datastore?

The initial intent was to keep NACM simple and make it easier to have high performance implementations.
NACM only allows the event-type to be tested, not any data within it. IMO the new notification work will
be significantly more expensive to implement high performance notification delivery.

<Eric> Understand.  For this high performance reason in the YANG Push work we do allow for subscriptions to be re-established if underlying object permissions change.

Do you see this NACM text providing a blocker for someone who desires such notification content filtering?  Some early yang-push use cases I am seeing are in the security and config change validation spaces.  As these have low transaction volumes, it may be viable to support such event based permissions mapping in implementation.

#3 Section 3.4.6

This doesn't really work for data rules on specific instances that get created
after the subscription starts. But applying NACM data rules to every descendant
node in a YANG push is going to be extremely slow. This gets even worse
for subscriptions with multiple receivers (as NACM has to be enforced for
each receiver). I would prefer to see a solution that forces YANG push
to enforce NACM at update generation time (before the notification
delivery system ever sees it) But this assumes YANG push is aware
of the active subscriptions, so not an ideal solution at all.

<Eric> understand, and agree these are valid approaches.   I am just hoping that the text doesn’t explicitly preclude implementations which might be able to accomplish notification based content filtering.  As the text currently says “out of scope”, my reading is that this not precluded.

Eric

Thanks,
Eric

Andy

Thanks.

NETCONF WG,

Thanks.

Mahesh and Mehmet

Mahesh & Mehmet

---

From: Andy Bierman <[email-masked]>
Date: Thu, 4 May 2017 08:01:57 -0700

On Thu, May 4, 2017 at 7:53 AM, Eric Voit (evoit) <[email-masked]> wrote:

>
>
> *From:* Andy Bierman, May 4, 2017 12:51 AM
>

It would be disruptive to change this because 6536-compliant
implementations send access-denied

> <Eric> Understand.  For this high performance reason in the YANG Push work
> we do allow for subscriptions to be re-established if underlying object
> permissions change.
>
>
>
> Do you see this NACM text providing a blocker for someone who desires such
> notification content filtering?  Some early yang-push use cases I am seeing
> are in the security and config change validation spaces.  As these have low
> transaction volumes, it may be viable to support such event based
> permissions mapping in implementation.
>

no -- see below

> <Eric> understand, and agree these are valid approaches.   I am just
> hoping that the text doesn’t explicitly preclude implementations which
> might be able to accomplish notification based content filtering.  As the
> text currently says “out of scope”, my reading is that this not precluded.
>
>
>

IMO it is OK to put this requirement on a YANG push implementation.
The pruning is done by YANG push, not NACM
Then NACM checks the event-type (if so configured)

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 4 May 2017 15:06:49 +0000

Thanks Andy.   I am good with the document.

From: Andy Bierman,  May 4, 2017 11:02 AM

On Thu, May 4, 2017 at 7:53 AM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:

#1 Section 3.1.3

<Eric> ok

It would be disruptive to change this because 6536-compliant implementations send access-denied

#2  Section 3.1.3

no -- see below

#3 Section 3.4.6

Eric

Andy

Thanks,
Eric

Andy

Thanks.

NETCONF WG,

Thanks.

Mahesh and Mehmet

Mahesh & Mehmet

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 4 May 2017 17:22:30 +0000

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:[email-masked]] On Behalf Of Mahesh Jethanandani
Sent: Wednesday, May 03, 2017 2:18 PM
To: Netconf <[email-masked]>
Subject: Re: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis

Folks,

Thanks.

NETCONF WG,

Thanks.

Mahesh and Mehmet

Mahesh & Mehmet

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 4 May 2017 17:32:40 +0000

One comment below, very bottom, <ALEX>
--- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Thursday, May 04, 2017 8:07 AM
To: Andy Bierman <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis

….

#3 Section 3.4.6

<ALEX> Is this something that could be added to NACM as a feature/extension to be applied to specific notification types?   Perhaps it does not need to be fully speced out in this document, but still described how this could be accommodated.  As mentioned in my other message, I do think this is an important limitation.  It is made for a reason, but still with possible scenarios that we can already anticipate (with other WG items that are WIP) which will call for that limitation to be overcome, so I think this warrants adding at a minimum a brief section discussing this.
</ALEX>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 4 May 2017 10:39:33 -0700

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 <[email-masked]

> 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:[email-masked]] *On Behalf Of *Mahesh
> Jethanandani
> *Sent:* Wednesday, May 03, 2017 2:18 PM
> *To:* Netconf <[email-masked]>
> *Subject:* Re: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis
>
>
>
> Folks,
>
>
>

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 4 May 2017 18:21:14 +0000

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

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:[email-masked]]
Sent: Thursday, May 04, 2017 10:40 AM
To: Alexander Clemm <[email-masked]>
Cc: Mahesh Jethanandani <[email-masked]>; Netconf <[email-masked]>
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.

Andy

On Thu, May 4, 2017 at 10:22 AM, Alexander Clemm <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

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

-          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:[email-masked]<mailto:[email-masked]>] On Behalf Of Mahesh Jethanandani
Sent: Wednesday, May 03, 2017 2:18 PM
To: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis

Folks,

Thanks.

NETCONF WG,

Thanks.

Mahesh and Mehmet

Mahesh & Mehmet

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Thu, 4 May 2017 11:28:48 -0700

On Thu, May 4, 2017 at 11:21 AM, Alexander Clemm <[email-masked]

> 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:[email-masked]]
> *Sent:* Thursday, May 04, 2017 10:40 AM
> *To:* Alexander Clemm <[email-masked]>
> *Cc:* Mahesh Jethanandani <[email-masked]>; Netconf <
> [email-masked]>
> On Thu, May 4, 2017 at 10:22 AM, Alexander Clemm <
> [email-masked]> wrote:
>
> Hi,
>
>
>

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 4 May 2017 18:41:09 +0000

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

Sent: Thursday, May 04, 2017 11:29 AM

On Thu, May 4, 2017 at 11:21 AM, Alexander Clemm <[email-masked]<mailto:[email-masked]>> 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”.

I could add text that says there is no consideration for specific datastores.

Andy

--- Alex

From: Andy Bierman [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, May 04, 2017 10:40 AM
To: Alexander Clemm <[email-masked]<mailto:[email-masked]>>
Cc: Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>; Netconf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis

Hi,

Andy

Thanks
--- Alex

Folks,

Thanks.

NETCONF WG,

Thanks.

Mahesh and Mehmet

Mahesh & Mehmet

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 May 2017 21:14:15 +0200

> but they apply to all instances in all datastores).  I can make this clear

Does NACM apply to an I2RS datastore? Just checking before a generic
all datastores quantifier is put in place. Perhaps it is safer to say
where we know NACM applies and leave the rest to be defined later.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 4 May 2017 13:02:39 -0700

> where we know NACM applies and leave the rest to be defined later.
It applies to all datastores.
The datastore may not support all the CRUD operations that NACM supports.
The subset that does apply is enforced.

The other variant (the datastore supports more operations than the
NACM CRUDX model supports) is not covered.

So NACM should be careful to say new operations not covered by CRUDX
are out of scope.

IMO the  I2RS user priority enforcement is part of the protocol, not NACM,
similar to NETCONF enforcing data-missing on a delete operation.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 May 2017 07:43:28 +0200

> similar to NETCONF enforcing data-missing on a delete operation.

Do we allow for the possibility to have datastores that use a
different access control model, if ever needed?

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 4 May 2017 22:55:27 -0700

> different access control model, if ever needed?

that would certainly be out of scope for this document.
If something else replaces NACM the server would advertise that module
instead of ietf-netconf-acm.

> /js'

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 09 May 2017 14:50:30 +0200 (CEST)

> I could add text that says there is no consideration for specific

Actually, the document already says:

3.2.  Datastore Access

   The same access control rules apply to all datastores, for example,
   the candidate configuration datastore or the running configuration
   datastore.

   Only the standard NETCONF datastores (candidate, running, and
   startup) are controlled by NACM.

Somehow this needs to be updated when the revised datastore work is
done.  E.g., I expect read access to intended to follow the same NACM
rules.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 May 2017 08:46:08 +0200

> done.  E.g., I expect read access to intended to follow the same NACM

Yes. NACM likely also applies to the <operational/> datastore (but
this follows already from the text that talks about 'state data').

My question, however, was about other future yet to be defined
'dynamic' datastores - does NACM make a statement of the form 'once an
implementation announces NACM, NACM applies to all datastores - no
exceptions' or do we leave it to the definition of future datastores
to declare whether NACM applies to it. There may be three possible
solutions:

a) Once an implementation supports NACM, NACM applies to all
   datastores (including any datastores defined in the future).

b) Once an implementation supports NACM, NACM applies to all
   conventional datastores and the operational state datastore.  Other
   datastores must define whether NACM applies to them.

   (This means, whenever a new datastore is introduced, the question
   whether NACM applies has to answered for the new datastore.)

c) Once an implementation supports NACM, NACM applies to all current
   and future datastore unless explicitely stated or signaled that
   NACM does not apply to a certain future datastore.

   (This is essentially b) but with a default that NACM applies unless
   things are explicitly regulated to be different.)

I just thought it is worth to take a moment to think about this
question.

/js

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 16 May 2017 14:02:04 -0700

Having reviewed all the e-mails, I believe that there are few issues that need to be resolved before we send the draft for publication. We need to agree on the language, even if we do have the exact text in the draft.

To begin with, do the authors have a response to the suggestions from Juergen prompted by the question from Alex? Are we leaving the NACM definition of any future datastores to the datastore draft, or are we saying NACM applies to all datastores?

To the point that Andy raised earlier, we need to have texts around datastores that provide more than CRUDX capabilities, including any protocol operations, e.g. priority, as something that is out of scope of this document.

NETCONF WG has moved to redefine its charter beyond NETCONF and RESTCONF. Therefore there is a real possibility of another protocol being discussed in the WG. Is there something in the NACM draft that restricts it to NETCONF/RESTCONF that other protocols cannot adopt? If so, can they be called out?

Thanks.

> On May 9, 2017, at 11:46 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 May 2017 14:32:32 -0700

On Tue, May 16, 2017 at 2:02 PM, Mahesh Jethanandani <
[email-masked]> wrote:

> Having reviewed all the e-mails, I believe that there are few issues that
> need to be resolved before we send the draft for publication. We need to
> agree on the language, even if we do have the exact text in the draft.
>
> To begin with, do the authors have a response to the suggestions from
> Juergen prompted by the question from Alex? Are we leaving the NACM
> definition of any future datastores to the datastore draft, or are we
> saying NACM applies to all datastores?
>
>
No. IMO the text should say NACM applies to NETCONF and RESTCONF
with the existing datastores.

NACM MAY be applied to other datastores that have similar operation sets.
Any new datastore specification needs to define how it maps to the NACM
CRUDX
model.  The datastore does not need to use NACM (e.g., datastore defines
something else
or does not use access control).

To the point that Andy raised earlier, we need to have texts around
> datastores that provide more than CRUDX capabilities, including any
> protocol operations, e.g. priority, as something that is out of scope of
> this document.
>
>
This would be outside the scope of NACM.
This is part of the RPC input validation.

> NETCONF WG has moved to redefine its charter beyond NETCONF and RESTCONF.
> Therefore there is a real possibility of another protocol being discussed
> in the WG. Is there something in the NACM draft that restricts it to
> NETCONF/RESTCONF that other protocols cannot adopt? If so, can they be
> called out?
>

If NACM needs to be changed in the future because a new or existing
protocol needs new features
then the WG will have to deal with it then.

Andy

> > On May 9, 2017, at 11:46 PM, Juergen Schoenwaelder <

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 21 May 2017 22:25:56 -0700

Andy,

> On May 16, 2017, at 2:32 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Tue, May 16, 2017 at 2:02 PM, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
> Any new datastore specification needs to define how it maps to the NACM CRUDX
> model.  The datastore does not need to use NACM (e.g., datastore defines something else

Can you update the draft with this text.

> This is part of the RPC input validation.

And clarify that operations outside of CRUDX are outside the scope of NACM. We can them move the document towards publication.

Thanks.

> If NACM needs to be changed in the future because a new or existing protocol needs new features
> > On May 9, 2017, at 11:46 PM, Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >> Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
> >>> On Thu, May 4, 2017 at 11:21 AM, Alexander Clemm <[email-masked] <mailto:[email-masked]>
> >>>> wrote:
> >>>
> > Fax:   +49 421 200 3103         <http://www.jacobs-university.de/ <http://www.jacobs-university.de/>>
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> 
> Mahesh Jethanandani
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
> 

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 May 2017 19:29:32 -0700

Hi,

The update is on github.
http://github.com/netconf-wg/rfc6536bis

I would like Martin to look it over before it is posted.

Andy

On Sun, May 21, 2017 at 10:25 PM, Mahesh Jethanandani <
[email-masked]> wrote:

> And clarify that operations outside of CRUDX are outside the scope of
> NACM. We can them move the document towards publication.
>
> Thanks.
>
>
>
>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 23 May 2017 09:15:19 +0200 (CEST)

> I would like Martin to look it over before it is posted.

Done, and the new text looks good.  I moved the new subsection to be
the first in 3.2, and I also fixed some minor terminology issues.

But, I wonder if we shouldn't make the document even less NETCONF
specific, and align the terminology to revised-datastores.  For
example, currently the document talks about access to "NETCONF
datastores".   With the new less protocol-specific terminology this
would simply be "datastore".

Also, we currently have this:

   A standalone RESTCONF server (i.e., not co-located with a NETCONF
   server) applies NACM rules to a conceptual datastore, since
   datastores are not supported in RESTCONF.

I don't think this is quite correct.  Even in a stand-alone RESTCONF
server there is an underlying conceptual datastore, for which NACM can
be used to control access.  

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 May 2017 12:35:33 -0700

> the first in 3.2, and I also fixed some minor terminology issues.
OK

> would simply be "datastore".

I would prefer not to make more changes.
I think it is OK for NETCONF, RESTCONF, and any protocols based on them.

> be used to control access.

I do not agree there is any RESTCONF requirement to implement datastores,
just the ability to apply NACM to the conceptual configuration datastore.

The text says there is an underlying conceptual datastore, so what is the
issue?

Andy

> > >> >>>> needed (I am not aware of specific use cases), but specifically
> with
> > >> the
> > >> >>>> nonimpact and interrelation with NACM should be discussed.  This
> can
> > >> be as

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 23 May 2017 21:41:12 +0200 (CEST)

> The text says there is an underlying conceptual datastore, so what is the

All datastores are conceptual.  The problem is that the text is
contradictory - it says that RC applies NACM to a datastore, since RC
doesn't support datastores.  This doesn't make sense.

Maybe we can simply remove this sentence.

/martin

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 23 May 2017 12:41:58 -0700

> On May 23, 2017, at 12:15 AM, Martin Bjorklund <[email-masked]> wrote:
> 
> would simply be "datastore”.

I would prefer this.

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 May 2017 20:25:24 -0700

> > would simply be "datastore”.

OK, but the operations are somewhat NETCONF specific.
We will try to make sure we do not create more inconsistencies than we
remove ;-)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 24 May 2017 09:16:50 +0200 (CEST)

> We will try to make sure we do not create more inconsistencies than we

Yes.  But I think what we should do is not any technical changes, just
align terminology.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 May 2017 19:20:50 -0700

> Yes.  But I think what we should do is not any technical changes, just

OK -- the term NETCONF datastore was used twice, now just datastore.
(pushed to github)

The term datastore appears a lot.  There are 3 variants:

    - datastore
    - configuration datastore
    - target datastore

With revised datastores these are not all the same anymore.
We probably need to go through the entire document and check if the
correct variant is used in each instance.

Are there other terms that are needed for alignment?

Does NACM need to reference the revised-datastores draft to import
terminology?

Andy

> > > >>>> Having reviewed all the e-mails, I believe that there are few
> issues
> > > that
> > > >>>> need to be resolved before we send the draft for publication. We
> need
> > > to
> > > >>>> protocol operations, e.g. priority, as something that is out of
> scope
> > > of
> > > >>>> this document.
> > > >>>>
> > > >>>>
> > > >>>>>>>> As mentioned in my message, I don’t think specific access
> control
> > > >>>> will be
> > > >>>>> 'dynamic' datastores - does NACM make a statement of the form
> 'once
> > > an

---

From: t.petch <[email-masked]>
Date: Sat, 27 May 2017 12:19:01 +0100

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
Sent: Saturday, May 27, 2017 3:20 AM

    - datastore

<tp>

Yes, Normative Reference please.

Tom Petch

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 28 May 2017 10:16:59 -0700

Hi,

Just be clear -- we will add explicit support for revised datastores, not
just a
normative reference for terminology.  The NACM CRUDX mappings for the
intended, applied, and operational datastores will be in this draft.

Are there any objections to adding revised datastore support to NACM?
This might be an expansion of scope for the charter item.

Andy