Subject: Re: [Netconf] LC on subscribed-notifications-10

From: Xufeng Liu <[email-masked]>
Date: Tue, 6 Mar 2018 19:55:48 +0000

Support for publication. The authors have resolve the issues raised recently..

Thanks,
- Xufeng

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of Kent Watsen
> Sent: Wednesday, February 28, 2018 6:09 PM
> To: [email-masked]
> Subject: [Netconf] LC on subscribed-notifications-10
> 
> 
> WG,
> 
> The authors of netconf-event-notifications have indicated privately that they
> believe this document is now ready for Last Call.
> 
> This starts a 2.5-week Last Call on draft-ietf-netconf-subscribed-notifications-10
> [1] The LC will end on March 17, or when active threads peter out.
> 
> Please send your comments on this thread. Reviews of the document, and
> statement of support, are particularly helpful to the authors.  If you have
> concerns about the document, please state those too.
> 
> Authors please indicate if you are aware of any IPR on the document.
> 
> 
> [1] https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-10
> 
> 
> Kent & Mahesh
> 
> 
> 
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 6 Mar 2018 23:46:05 +0000

Yes, support,

Igor
From:Kent Watsen
To:[email-masked],
Date:2018-02-28 18:09:31
Subject:[Netconf] LC on subscribed-notifications-10

WG,

The authors of netconf-event-notifications have indicated privately that they believe this document is now ready for Last Call.

This starts a 2.5-week Last Call on draft-ietf-netconf-subscribed-notifications-10 [1]
The LC will end on March 17, or when active threads peter out.

Please send your comments on this thread. Reviews of the document, and statement of support, are particularly helpful to the authors.  If you have concerns about the document, please state those too.

Kent & Mahesh

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 7 Mar 2018 02:33:17 +0000

Yes, support.

Tianran

> Sent: Thursday, March 01, 2018 7:09 AM
> To: [email-masked]
> The authors of netconf-event-notifications have indicated privately that
> they believe this document is now ready for Last Call.
> 
> This starts a 2.5-week Last Call on
> draft-ietf-netconf-subscribed-notifications-10 [1] The LC will end on March
> 17, or when active threads peter out.
> 
> [1]
> https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notification
> s-10
> 
> 
> Kent & Mahesh
> 
> 
> 
>

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 7 Mar 2018 22:24:29 +0100

+1 on subscribed-notifications

Viele Grüße,

Henk

---

From: Robert Wilton <[email-masked]>
Date: Mon, 12 Mar 2018 16:40:42 +0000

Hi,

Some minor comments on this draft.  I've not read/reviewed all of it 
yet, so some more comments may follow.  But generally I am supportive of 
publishing this draft.

   I'm happy to leave it to the authors discretion on whether and how 
they want to address these.

1. I noted that neither the title nor abstract mention YANG or network 
configuration.  Nor do they mention that they define a YANG data model.

2. Intro:
  - Should security be somewhere in the intro section?

3. Section 1.1:
- Operational counters and instrumentation, it wasn't really clear to me 
whether, or how the draft really addresses this point.

- State change notification => "Subscription state change notifications"?

4. Sec 1.2:
- Configuration isn't necessarily persistent across reboots.  E.g. a 
configured subscription over something like I2RS.  Perhaps expand that 
configured subscriptions are normally persistent across reboots, but 
that depends on the behavior of the configuration subsystem.

- Steam: Is this really a set, or a sequence.  Perhaps ... "A continuous 
chronologically ordered sequence of events ..."?  If you change this, 
then perhaps grep for usage of "set" in the draft to see if they should 
be changed to sequence.

- I found the description of "Subscription" to be somewhat unclear.

5 Sec 1.3:

- I would have moved section 1.3 to the start of section 2.

- "starts pushing notification messages" -> "starts pushing notification 
messages to the subscriber/receiver".

- In paragraph starting "The lifetype or a dynamic" ... "running 
configuration" -> "applied configuration".

- In para starting "Configured subscriptions".  Should mention that 
subscriptions can also be killed by someone else with appropriate 
permissions.

- In para starting "The publisher MAY",  "MAY decide to" => "MAY", in 
two places.  In general I would suggesting checking all the MUST/MAYs 
and perhaps try to term them more explicit things that they 
MUST/MAY/SHOULD do.

6 Sec 2.

- Does this section need an intro, perhaps if section 1.3 moved here 
that would help?

- Sec 2.1 last paragraph.  Is this right that it must have access to all 
event records?  I wasn't sure how this tied in with YANG push where a 
client may not have access to read some nodes.  In that case, nodes that 
can't be read are left out (e.g. like a NETCONF GET request).  I know 
that YANG push covers this is more detail, but didn't know whether this 
paragraph correctly stands on its own?

7. 2.3 Qos, para starting "a dscp": "Where provided, this marking" => 
"Where provided, and supported, this marking" ...

8 2.4. Dynamic subscriptions

- Would writing "event streams" be better than "targets"?

- Diagram in 2.4.1, I found this diagram a bit tricky to 
read/interpret.  One particular question: Can you modify a subscription 
for a suspended receiver.

- In para starting "Failed modify", 'modify' => '"modify subscription"'.

9 2.4.2. Establishing a subscription:
  "It MUST be possible to support" => "A publisher MUST support". I 
would suggest changing both cases.

10. In para starting "an optional start time", perhaps also describe 
what happens if no start time has been provided.  Or perhaps just keep 
the first sentence and refer to 2.4.2.1 for more details.

11. In para starting "In the publisher", "it provides an identifier" => 
"it replies with an identifier"?

12. Sec 2.4.2.1, first paragraph:
   "then be followed by event records" => "then be followed by a replay 
complete event and then by event records"?

13. Sec 2.4.3, modify description tree output.  Identifier is optional, 
should be marked as mandatory?  Or otherwise what happens if it is not 
provided?

14. Sec 2.4.4.
- I would have called this "ending a subscription, or terminating a 
subscription" rather than "delete" because the subscription wasn't 
created, it was established.

- The text mentions the publisher rejecting a subscription, when can 
this happen?  Presumably only if the subscription id is not valid, or if 
it doesn't own it.  Perhaps check that this is consistent with how the 
text describes killing a subscription.

15 Sec 2.4.6
- Perhaps tweak the wording for "specifically ... specific".

16. Sec 2.5
"persistence across reboots" => "persistence across publisher reboots"?

Now skipping to Section 5.3 Security considerations!
- "all RPC requests" => "all subscriber RPC requests"?

- "MUST have the ability" => Something along the lines => Publishers 
MUST ensure that they have sufficient resources to fulfill a dynamic 
subscription request or otherwise reject the request, and provide ...

- "excessive use of system resources" => "excessive use of system 
resources on publisher or receiver".

- "No notification messages SHOULD be sent" => "Notification messages 
SHOULD NOT be sent".  Doesn't => Does not.

- Last paragraph, "it SHOULD NOT be assumed" => it cannot be assumed.

I will try and provide further comments between sec 2.5 and 5.3, but I'm 
somewhat short of time.

Thanks,
Rob

On 28/02/2018 23:09, Kent Watsen wrote:
> .

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 12 Mar 2018 21:58:53 +0000

> From: Robert Wilton -X, March 12, 2018 12:41 PM
> 
> Hi,
> 
> Some minor comments on this draft.  I've not read/reviewed all of it yet, so
> some more comments may follow.  But generally I am supportive of publishing
> this draft.

Thanks Robert.   

I have incorporated tweaks as-per below.  These updates can be seen within the working draft -v11 at:
https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-subscribed-notifications-11.txt 

>    I'm happy to leave it to the authors discretion on whether and how they
> want to address these.
> 

This is true, and I think ok.     Just like RFC-5277, it is possible to subscribe to non-YANG streams.
 
>   - Should security be somewhere in the intro section?

Do you see a particular need to emphasize security here?  Not sure why there should be a specific break-out here.

> whether, or how the draft really addresses this point.

There are counters for the number of events which pass and fail filters for a subscription on a stream.  These are the YANG objects "pushed-notifications" & "excluded-notifications"

I have tweaked the text to "per-subscription operational counters" to cover this.

> - State change notification => "Subscription state change notifications"?

Every time "state change notification" is used, the word subscription is easily matched up.   So it seems to me to be more readable to use a shorter term versus a longer one.

> 4. Sec 1.2:
> - Configuration isn't necessarily persistent across reboots.  E.g. a configured
> subscription over something like I2RS.  Perhaps expand that configured
> subscriptions are normally persistent across reboots, but that depends on the
> behavior of the configuration subsystem.

I made it: 
Configured subscription: A subscription installed via a configuration interface.  Typically a configured subscription is placed into a configuration subsystem which supports persistence across reboots.
 
> chronologically ordered sequence of events ..."?  If you change this, then
> perhaps grep for usage of "set" in the draft to see if they should be changed to
> sequence.

I like the addition of "chronologically", put that word in.  Regarding "sequence": with "ordered" we likely have that covered sufficiently.  Plus RFC-5277 used  "set", so this is closer match to the original stream definition.
 
> - I would have moved section 1.3 to the start of section 2.

Ack.  It has moved around over previous iterations.  I kind of got used to it being in the Intro section.
 
> - "starts pushing notification messages" -> "starts pushing notification messages
> to the subscriber/receiver".

Made it "back to the subscriber".

> - In paragraph starting "The lifetype or a dynamic" ... "running configuration" ->
> "applied configuration".

Changed

> subscriptions can also be killed by someone else with appropriate permissions.

We thought about this.  It seemed to be too much detail this early in the document.  It should be adequately covered in later sections.

> - In para starting "The publisher MAY",  "MAY decide to" => "MAY", in two
> places.

Changed

>  In general I would suggesting checking all the MUST/MAYs and perhaps
> try to term them more explicit things that they MUST/MAY/SHOULD do.
> 
> 6 Sec 2.
> 
> - Does this section need an intro, perhaps if section 1.3 moved here that would
> help?

To me it feels redundant to have that right after the intro 1.3.   If other people feel 1.3 should be moved down, I have no problem with it.
 
> - Sec 2.1 last paragraph.  Is this right that it must have access to all event
> records? 

Yes

> I wasn't sure how this tied in with YANG push where a client may not
> have access to read some nodes.  In that case, nodes that can't be read are left
> out (e.g. like a NETCONF GET request).  I know that YANG push covers this is
> more detail, but didn't know whether this paragraph correctly stands on its
> own?

Current paragraph is correct.  The idea is you shouldn't allow someone to subscribe to a stream containing any content they are not allowed to see.  Access control is to the stream rather than the content.  This is a reason why yang push is a more flexible approach in many cases.
 
> 7. 2.3 Qos, para starting "a dscp": "Where provided, this marking" => "Where
> provided, and supported, this marking" ...

As it is a feature, if it is successfully provided, it must be supported.
 
> - Would writing "event streams" be better than "targets"?

As dynamic subscriptions also apply to datastores (as augmented by yang-push), it is better to leave the more general term.
 
> - Diagram in 2.4.1, I found this diagram a bit tricky to read/interpret.  One
> particular question: Can you modify a subscription for a suspended receiver.

There is a line from receiver suspended for this, so yes.
 
> - In para starting "Failed modify", 'modify' => '"modify subscription"'.

Changed
 
>   "It MUST be possible to support" => "A publisher MUST support". I would
> suggest changing both cases.

Done
 
> 10. In para starting "an optional start time", perhaps also describe what
> happens if no start time has been provided.  Or perhaps just keep the first
> sentence and refer to 2.4.2.1 for more details.

Added: Where there is no start time, the subscription starts immediately.

> 11. In para starting "In the publisher", "it provides an identifier" => "it replies
> with an identifier"?

Changed

> complete event and then by event records"?

Made it:
The end of these historical event records is identified via a "replay-completed" state change notification.  Any event records generated since the subscription establishment may then follow.
 
> 13. Sec 2.4.3, modify description tree output.  Identifier is optional, should be
> marked as mandatory?  Or otherwise what happens if it is not provided?

Good catch.  Re-made it mandatory.  Not sure where that got dropped.
 
> 14. Sec 2.4.4.
> - I would have called this "ending a subscription, or terminating a subscription"
> rather than "delete" because the subscription wasn't created, it was
> established.

The only reason we couldn't use "create" was that it was already used in RFC-5277.   Delete should be fine.
 
> - The text mentions the publisher rejecting a subscription, when can this
> happen?

Actually it says "any" not "a".  The implication is that no other effects anywhere based on a rejected subscription request.  E.g., don't try to guess which subscription to delete.

But there is still a case for "a".  What if a subscriber (with identical credentials) established the referenced subscription on a different transport session?  The delete still should not work unless it comes on the original transport.

>  Presumably only if the subscription id is not valid, or if it doesn't own
> it.  Perhaps check that this is consistent with how the text describes killing a
> subscription.

I think it works.
 
> - Perhaps tweak the wording for "specifically ... specific".

Tweaked

> "persistence across reboots" => "persistence across publisher reboots"?

Done
 
> - "all RPC requests" => "all subscriber RPC requests"?

Should be ok per the earlier words in the sentence.
 
> - "MUST have the ability" => Something along the lines => Publishers MUST
> ensure that they have sufficient resources to fulfill a dynamic subscription
> request or otherwise reject the request, and provide ...

Incorporated something similar.

> - "excessive use of system resources" => "excessive use of system resources on
> publisher or receiver".

Updated

> SHOULD NOT be sent".  Doesn't => Does not.

Updated
 
> - Last paragraph, "it SHOULD NOT be assumed" => it cannot be assumed.

Updated

> I will try and provide further comments between sec 2.5 and 5.3, but I'm

Appreciated, Thanks Again!
Eric

---

From: Robert Wilton <[email-masked]>
Date: Tue, 13 Mar 2018 10:26:34 +0000

> Do you see a particular need to emphasize security here?  Not sure why there should be a specific break-out here.
Only to make it clear that it has been considered, and the draft 
provides a solution for it.

> I have tweaked the text to "per-subscription operational counters" to cover this.
Yes, that helps clarify.

> Every time "state change notification" is used, the word subscription is easily matched up.   So it seems to me to be more readable to use a shorter term versus a longer one.
Ok, so when I first read this I thought that it was talking about the 
changes in state within the data, rather than state changes of the 
subscriptions themselves.  Personally, I still think that this is worth 
clarifying, but I'll leave the decision to the authors.

> Configured subscription: A subscription installed via a configuration interface.  Typically a configured subscription is placed into a configuration subsystem which supports persistence across rebo…
Looks good.

> I like the addition of "chronologically", put that word in.  Regarding "sequence": with "ordered" we likely have that covered sufficiently.  Plus RFC-5277 used  "set", so this is closer match to th…
I still strongly prefer calling it a sequence, because I think that is 
what it is :-)

I quickly looked up a couple of definitions of stream in computer 
science literature and they all refer to them as sequences not sets.  Is 
the steam being referenced to this draft that same as what a normal 
software engineer would think of as a stream?

Is a stream ever allowed to contain duplicate values, e.g. on a replay 
it is possible to put the same events into the stream?  If events are 
always unique then set is fine, otherwise set just seems like the 
incorrect term.

> Current paragraph is correct.  The idea is you shouldn't allow someone to subscribe to a stream containing any content they are not allowed to see.  Access control is to the stream rather than the…
OK.

> As dynamic subscriptions also apply to datastores (as augmented by yang-push), it is better to leave the more general term.
OK, I think that I'm still struggling to create a good mental picture of 
how everything fits together.

I assumed that subscriptions only subscribe to event streams (e.g. from 
first sentence in section 1).  Hence, I was assuming that in the case of 
YANG push, that the change notifications to a datastore would 
effectively be a new event stream that could be subscribed to.  Are you 
saying that it is something else?  This might need to be clarified 
somewhere.

> There is a line from receiver suspended for this, so yes.
I think that I find it confusing as to what is an external event coming 
from a subscriber or receiver vs internal state changes.

OK, so I think that I have finally figured out what this diagram is 
meant to be showing :-)

Hence, I think that it might help to explicitly list the external events 
below the diagram:

- External events from a subscriber: establish-subscription, 
modify-subscription, ...

- Internal states: start, receiver-ACTIVE, receiver-SUSPENDED, end.

> Added: Where there is no start time, the subscription starts immediately.
OK.
> The end of these historical event records is identified via a "replay-completed" state change notification.  Any event records generated since the subscription establishment may then follow.
OK.

> The only reason we couldn't use "create" was that it was already used in RFC-5277.   Delete should be fine.
OK.

> But there is still a case for "a".  What if a subscriber (with identical credentials) established the referenced subscription on a different transport session?  The delete still should not work unl…
The first sentence of that paragraph already states that it is on the 
same transport session.  My interpretation of the current text is that a 
publisher can arbitrarily choose not to cancel a subscription.  I think 
that the text would be better if it was more explicit.

E.g. perhaps replace: " If the publisher rejects the request, the
    request has no impact whatsoever on any subscription.

with something like:

"If the delete request does not match a known subscription id of a 
subscription established on the same transport session, then it MUST be 
rejected with no changes to the system".

Thanks,
Rob

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 13 Mar 2018 13:44:09 +0000

Hi Rob,

Reducing to the open dialogs...

> From: Robert Wilton, March 13, 2018 6:27 AM
> >> 2. Intro:
> Only to make it clear that it has been considered, and the draft provides a
> solution for it.

Inserted "and access permissions" in the second sentence to make it:

"Effectively this enables a "subscribe then publish" capability where the customized information needs and access permissions of each target receiver are understood by the publisher before subscribed event records are marshaled and pushed."

> >> - Steam: Is this really a set, or a sequence.  Perhaps ... "A
> >> continuous chronologically ordered sequence of events ..."?  If you
> >> change this, then perhaps grep for usage of "set" in the draft to see
> >> if they should be changed to sequence.
> > I like the addition of "chronologically", put that word in.  Regarding
> "sequence": with "ordered" we likely have that covered sufficiently.  Plus RFC-
> 5277 used  "set", so this is closer match to the original stream definition.
> I still strongly prefer calling it a sequence, because I think that is what it is :-)
>
> I quickly looked up a couple of definitions of stream in computer science
> literature and they all refer to them as sequences not sets.  Is the steam being
> referenced to this draft that same as what a normal software engineer would
> think of as a stream?
> 
> Is a stream ever allowed to contain duplicate values, e.g. on a replay it is
> possible to put the same events into the stream?

Event records are not be repeated on a subscription, even with replay.

>  If events are always unique
> then set is fine, otherwise set just seems like the incorrect term.

I really have no problem with "sequence".  The only issue is that we had requests from the original authors of RFC-5277 to keep the stream definition as close to the original as feasible.   If anyone else wants "sequence" and there are no objections, I am absolutely happy to convert.

> > As dynamic subscriptions also apply to datastores (as augmented by yang-
> push), it is better to leave the more general term.
> OK, I think that I'm still struggling to create a good mental picture of how
> everything fits together.
> 
> I assumed that subscriptions only subscribe to event streams (e.g. from first
> sentence in section 1).  Hence, I was assuming that in the case of YANG push,
> that the change notifications to a datastore would effectively be a new event
> stream that could be subscribed to.  Are you saying that it is something
> else?  This might need to be clarified somewhere.

Actually what you were assuming was the original definition of "stream".  I.e., it was how stream was first defined in 2014 in yang-push up until -v04 in 2016.   But with the advent of NMDA, we wanted to adopt the definitions of "datastore" rather than create a mapping that forced the NMDA datastores to be associated 1:1 with stream names.

More is described in yang-push.  Note that In the yang module, target is a 'choice' statement with only a single case explored within subscribed-notifications.  So detailing in this document what is expressed as an actual choice in yang-push seemed confusing. 
 
> - External events from a subscriber: establish-subscription,

As each of these has its own section in the document, I am hesitant to add lots of verbal complexity to the diagram.  If other people think this would be helpful, it certainly could and should be added.

> - Internal states: start, receiver-ACTIVE, receiver-SUSPENDED, end.

In the text above the diagram, I added the sentence "Each state is shown in its own box".  Other text does describe the internal states.

> > Actually it says "any" not "a".  The implication is that no other effects
> anywhere based on a rejected subscription request.  E.g., don't try to guess
> which subscription to delete.
> >
> > But there is still a case for "a".  What if a subscriber (with identical
> credentials) established the referenced subscription on a different transport
> session?  The delete still should not work unless it comes on the original
> transport.
 
Ok.  Made it:
If the delete request does not match a known subscription established on the same transport session, then it MUST be rejected with no changes to the publisher.

Thanks,
Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 14 Mar 2018 09:39:00 +0100 (CET)

Hi,

"Eric Voit (evoit)" <[email-masked]> wrote:
> > yet, so

Perhaps "A YANG Data Model for Event Stream Subscriptions"?

Or something along these lines in the abstract.

Even though the streams may not be YANG-defined, the subscription
mechanism is YANG based.

[...]

> > - State change notification => "Subscription state change
> > - notifications"?
> 
> Every time "state change notification" is used, the word subscription
> is easily matched up.  So it seems to me to be more readable to use a
> shorter term versus a longer one.

I think that in most cases you are right.  But I suggest you clarify
this the first time the term is used, in 1.1:

OLD:

   o  state change notifications (e.g., publisher driven suspension,
      parameter modification)

NEW:

   o  subscription state change notifications (e.g., publisher driven
      suspension, parameter modification)

[...]

> Current paragraph is correct.  The idea is you shouldn't allow someone
> to subscribe to a stream containing any content they are not allowed
> to see.  Access control is to the stream rather than the content.

But it seems that YANG push filters out the nodes that you don't have
access to.

Your statement:

  Access control is to the stream rather than the content.

seems to imply that in order to subscribe to changes to the datastore,
you need full access to all nodes covered by the filter.

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 14 Mar 2018 13:28:57 +0000

Hi Martin,

> From: Martin Bjorklund, March 14, 2018 4:39 AM
> 
> Hi,
> 
> > > yet, so some more comments may follow.  But generally I am
> > > supportive of publishing this draft.
> >
> > Thanks Robert.
> >
> > >    I'm happy to leave it to the authors discretion on whether and
> > > how  they want to address these.
> > >
> > > 1. I noted that neither the title nor abstract mention YANG or
> > > network configuration.  Nor do they mention that they define a YANG
> > > data model.
> >

Ok.   I made the first sentence of the abstract:
"This document defines capabilities, operations, and a YANG Data Model for the customized establishment of subscriptions upon a publisher's event streams."
 
> I think that in most cases you are right.  But I suggest you clarify this the first
> time the term is used, in 1.1:
> 
> OLD:
> 

Done

> > > have access to read some nodes.  In that case, nodes that can't be
> > > read are left out (e.g. like a NETCONF GET request).  I know that
> > > YANG push covers this is more detail, but didn't know whether this
> But it seems that YANG push filters out the nodes that you don't have access
> to.

Yes.  For subscriptions to datastores, YANG push filters out data nodes for which the receiver has no access (just like a Get)    But for subscription to event streams, it is assumed that any event records placed on a stream permitted for that receiver is authorized content (just like RFC-5277).   Effects like this are why the two drafts, as well as the YANG model targets and filters for datastores and to streams have been separated.

> seems to imply that in order to subscribe to changes to the datastore, you
> need full access to all nodes covered by the filter.

As a stream and a datastore are different, hopefully my comment above clears this up.   

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 14 Mar 2018 14:58:41 +0100 (CET)

Hi,

"Eric Voit (evoit)" <[email-masked]> wrote:
> "This document defines capabilities, operations, and a YANG Data Model
> for the customized establishment of subscriptions upon a publisher's
> event streams."

Ok.

> > access
> Yes.  For subscriptions to datastores, YANG push filters out data
> nodes for which the receiver has no access (just like a Get).

Ok.

> But for
> subscription to event streams, it is assumed that any event records
> placed on a stream permitted for that receiver is authorized content
> (just like RFC-5277).

Hmm.  This is not how it is defined in RFC 5277:

   After generation of the <notification> element, access control is
   applied by the server.  If a session does not have permission to
   receive the <notification>, then it is discarded for that session,
   and processing of the internal event is completed for that session.

Also, NACM is designed to drop notifications that the client doesn't
have access to.

> Effects like this are why the two drafts, as
> well as the YANG model targets and filters for datastores and to
> streams have been separated.
>
> > Your statement:
> > 
> > you

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 14 Mar 2018 15:35:53 +0000

(reducing to the single open item, and adding Andy + Alex to the "to")

> From: Martin Bjorklund, March 14, 2018 9:59 AM
> 
> Hi,
> 

Agree.   I should not have said "just like 5277".   More below.

> Also, NACM is designed to drop notifications that the client doesn't have
> access to.

A few years ago during early discussions, Alex and I remember Andy asking that per receiver access control not be applied to traffic coming out of a stream.    We took that to mean that a receiver should get all the event records on a stream, without any per-notification filtering.  This is what drove the current text.

Per RFC-6536, section 3.4.6., the outgoing <notification> authorization is able to look at the notification event type, and if a receiver is authorized to receive the notification event type, then it is also authorized to receive any data it contains.  

Reconsidering this, perhaps Alex and I interpreted Andy's intent wrong.  And Andy actually requested the current event type behavior which NACM can currently perform on the RFC-5277 NETCONF event stream, but no other filtering of event records beyond that.

If that is the case, and this capability is desired by the WG, Alex and I would be happy to replicate the relevant text from RFC-5277 section 3.2 to draft-ietf-netconf-subscribed-notifications to cover this.

Thanks,
Eric

> > Effects like this are why the two drafts, as well as the YANG model
> > targets and filters for datastores and to streams have been separated.
> >
> > > Your statement:
> > >
> > > seems to imply that in order to subscribe to changes to the
> > > datastore, you need full access to all nodes covered by the filter.
> >

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Mar 2018 09:52:32 -0700

On Wed, Mar 14, 2018 at 8:35 AM, Eric Voit (evoit) <[email-masked]> wrote:

> A few years ago during early discussions, Alex and I remember Andy asking
> that per receiver access control not be applied to traffic coming out of a
> stream.    We took that to mean that a receiver should get all the event
> records on a stream, without any per-notification filtering.  This is what
> drove the current text.
>
> Per RFC-6536, section 3.4.6., the outgoing <notification> authorization is
> able to look at the notification event type, and if a receiver is
> authorized to receive the notification event type, then it is also
> authorized to receive any data it contains.
>
> Reconsidering this, perhaps Alex and I interpreted Andy's intent wrong.
> And Andy actually requested the current event type behavior which NACM can
> currently perform on the RFC-5277 NETCONF event stream, but no other
> filtering of event records beyond that.
>
>
I think the notification event type filtering is still applicable.

I remember some discussions about applying NACM to YANG Push subscriptions.
Of course the client needs permission to receive <push-update> events.
The issue for YP is that this is the only access control provided.

In order to support NACM for the contents of <push-update> events, the
client
MUST have permission to read every data node specified in the filters for
a subscription. This is checked when the subscription is configured or
activated.
If a filter-ref filter is changed so this is no longer true, then the
server MUST
suspend or terminate the subscription.

IMO even this is quite an implementation burden, but less than having the
server check NACM rules for every descendant node of every edited node for
every
<push-update>.

If that is the case, and this capability is desired by the WG, Alex and I
> would be happy to replicate the relevant text from RFC-5277 section 3.2 to
> draft-ietf-netconf-subscribed-notifications to cover this.
>
> Thanks,
> Eric
>

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 14 Mar 2018 17:14:51 +0000

(Look for <Eric2>  trying to keep things legible for those using text only email clients)

From: Andy Bierman, March 14, 2018 12:53 PM

On Wed, Mar 14, 2018 at 8:35 AM, Eric Voit (evoit) <mailto:[email-masked]> wrote:
(reducing to the single open item, and adding Andy + Alex to the "to")

> "Eric Voit (evoit)" <mailto:[email-masked]> wrote:
> > Hi Martin,
> >
> > But for

<Eric2>  Based on this, I will add the relevant RFC-5277 text into subscribed notifications.  Look for a link to a draft version on github shortly.  Will send link to this thread.
</Eric2>

In order to support NACM for the contents of <push-update> events, the client
MUST have permission to read every data node specified in the filters for
a subscription. This is checked when the subscription is configured or activated.
If a filter-ref filter is changed so this is no longer true, then the server MUST
suspend or terminate the subscription.

IMO even this is quite an implementation burden, but less than having the
server check NACM rules for every descendant node of every edited node for every
<push-update>.

<Eric2> Agree that either is a valid method of achieving the requirements of yang-push.
</Eric2>

Eric2

Thanks,
Eric

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 14 Mar 2018 20:11:49 +0000

Per below, updated text now at:
https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-subscribed-notifications-11.txt

Specifically:

Section 2.1.

   Access control permissions may be used to silently exclude event
   records from within a stream for which the subscriber has no read
   access.  As an example of how this might be accomplished, see
   [RFC6536bis] section 3.4.6.  Note that per Section 2.7 of this 
   document, subscription state change notifications are never 
   filtered out.

   If no access control permissions are in place for stream content,
   then a receiver MUST be allowed access to all the event records on
   the stream.

Also I modified the definition of:

          leaf excluded-notifications {
            type yang:counter64;
            config false;
            description
              "Operational data which provides the number of event
               records from a stream explicitly removed either via a 
               stream filter or an access control filter so that they 
               are not passed to a receiver.";
            }

It is likely sufficient to have a single counter here.  But if people would prefer independent counters for stream filter exclusions and access control exclusions, that can easily be included.

Eric

> From: Eric Voit (evoit)
> Sent: Wednesday, March 14, 2018 1:14 PM
> To: 'Andy Bierman' <[email-masked]>
> Cc: Martin Bjorklund <[email-masked]>; [email-masked]; Robert Wilton -X
> (rwilton - ENSOFT LIMITED at Cisco) <[email-masked]>;
> [email-masked]; [email-masked]; draft-ietf-netconf-subscribed-
> [email-masked]
> Subject: RE: [Netconf] LC on subscribed-notifications-10
> 
> A few years ago during early discussions, Alex and I remember Andy asking that
> per receiver access control not be applied to traffic coming out of a
> stream.    We took that to mean that a receiver should get all the event records
> on a stream, without any per-notification filtering.  This is what drove the
> current text.
> 
> Per RFC-6536, section 3.4.6., the outgoing <notification> authorization is able
> to look at the notification event type, and if a receiver is authorized to receive
> the notification event type, then it is also authorized to receive any data it
> contains.
> 
> Reconsidering this, perhaps Alex and I interpreted Andy's intent wrong.  And
> Andy actually requested the current event type behavior which NACM can
> <Eric2>  Based on this, I will add the relevant RFC-5277 text into subscribed
> notifications.  Look for a link to a draft version on github shortly.  Will send link
> to this thread.
> </Eric2>
> 
> MUST have permission to read every data node specified in the filters for a
> subscription. This is checked when the subscription is configured or activated.
> every <push-update>.
> If that is the case, and this capability is desired by the WG, Alex and I would be
> happy to replicate the relevant text from RFC-5277 section 3.2 to draft-ietf-
> netconf-subscribed-notifications to cover this.
> 
> Thanks,
> Eric
> 
> Andy
> 
>

---

From: Balazs Lengyel <[email-masked]>
Date: Sun, 18 Mar 2018 00:00:53 +0100

Hello,

My last call review. Sorry if some of the comments are already mentioned.
I  think the document is in a good shape, ready to progress onwards (if 
my MAJOR comments are clarified.).

Abstract:  "Also defined are delivery mechanisms for instances of the 
resulting notification messages."
Aren't these in other drafts?

P5)
Dynamic subscriptions can only be modified via an RPC request made by 
the original subscriber.
Is it stated/documented that at least for netconf the same session must 
be used?

P7))
"If access control permissions are in use to secure publisher content,
    then for event records to be sent to a receiver, that receiver MUST
    be allowed access to all the event records on the stream."

So if in Yang-push I subscribe to 2 separate objects, but I only have
rights to one of them, I will not get notifications when the other changes?

P10) MAJOR
In the tree it is indicated that establish-subscription has an 
output(subscription-id). This is missing from the Yang Model

P13) It should be stated that delete-subscription MUST always succeed if 
the subscription exists.

P15) second list: transport parameter should be mentioned

P22)
The publisher may decide to terminate a subscription for any other 
reason too (license expiry, configuration switch, internal error, etc.)

P26) MAJOR
The tree indicates everything as readOnly while a lot of this can be 
configured.

P32) Shouldn't the transport identities be defined in the relevant 
transport drafts/RFCs?

P34) There really should be a filter example to show how it is applied 
against the notification.

What happens if multiple event records are carried in one notification 
message. Is that possible? It should be stated explicitly somewhere.
How is the filter applied in this case?

P37) Why is require-instance for leaf stream false?

P39) grouping receiver-info: "Defines where and how to get notification 
messages" IMHO use send instead of get in the first line of the description

P48) "A list of pre-positioned filters"   use pre-configured or 
pre-provisioned

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Rohit R Ranade <[email-masked]>
Date: Sun, 18 Mar 2018 04:58:39 +0000

hi all,

If user has permission to read on parent but not child, and if user has subscription filter on parent, the user should be able to get changes on parent ONLY even if both parent and child were modified..
So I feel nacm rules need to be applied at the time of generating push updates..user should not get any updates if only child is updated.. this will be my expectation as an user..

From:Andy Bierman
To:Eric Voit (evoit),
Cc:[email-masked],[email-masked],[email-masked],
Date:2018-03-14 22:23:10
Subject:Re: [Netconf] LC on subscribed-notifications-10

On Wed, Mar 14, 2018 at 8:35 AM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:
(reducing to the single open item, and adding Andy + Alex to the "to")

> "Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]>> wrote:
> > Hi Martin,
> >
> > But for

Thanks,
Eric

Andy

---

From: <[email-masked]>
Date: Sun, 18 Mar 2018 02:59:14 -0700

Hi Rohit,

Yes.  Conceptually, it is cleanest to apply the filter on the event contents
with each update.  At the same time, in the interest of performance, Andy
and others have raised the issue of performance penalty if every update has
to be subjected to a filter.  One option is for an implementation to simply
reject a subscription if there is a chance that it might contain information
that would have to be filtered (i.e. do the NACM check at the time the
subscription is created), and in case of NACM changes later that might
affect subscriptions, to terminate the subscription (and let users
resubscribe).  

--- Alex

From: Rohit R Ranade <[email-masked]> 
Sent: Saturday, March 17, 2018 9:59 PM
To: Andy Bierman <[email-masked]>; Eric Voit (evoit) <[email-masked]>
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: [SPAM?] RE: [Netconf] LC on subscribed-notifications-10

hi all, 

If user has permission to read on parent but not child, and if user has
subscription filter on parent, the user should be able to get changes on
parent ONLY even if both parent and child were modified.. 
So I feel nacm rules need to be applied at the time of generating push
updates..user should not get any updates if only child is updated.. this
will be my expectation as an user..

From:Andy Bierman

To:Eric Voit (evoit),

Cc:[email-masked],[email-masked],netco
[email-masked],

Date:2018-03-14 22:23:10

 

On Wed, Mar 14, 2018 at 8:35 AM, Eric Voit (evoit) <[email-masked]
<mailto:[email-masked]> > wrote:

> "Eric Voit (evoit)" <[email-masked] <mailto:[email-masked]> > wrote:
> > Hi Martin,
> >
> > But for

Per RFC-6536, section 3.4.6., the outgoing <notification> authorization is
able to look at the notification event type, and if a receiver is authorized
to receive the notification event type, then it is also authorized to
receive any data it contains.

If a filter-ref filter is changed so this is no longer true, then the server
MUST

<push-update>.

Thanks,
Eric

Andy

---

From: Rohit R Ranade <[email-masked]>
Date: Sun, 18 Mar 2018 13:15:56 +0000

Hi Alex,

1. If this is a push update specific point, the newly updated Nacm rfc need to mention this point specifically.
2. If a session had subcribed to multiple paths and it was ok, but another session added a deny rule for one of the path, are all subscriptions dropped ? how will user know what caused the termination.we may need to add to the subscription termination list
3. also when a nacm read-deny rule is configured, we may need to scan through all filters and terminate accordingly.. whether the nacm rfc can mention this point
From:[email-masked]
To:Rohit R Ranade,'Andy Bierman','Eric Voit (evoit)',
Cc:[email-masked],[email-masked],
Date:2018-03-18 15:29:20
Subject:RE: [SPAM?] RE: [Netconf] LC on subscribed-notifications-10

Hi Rohit,

Yes.  Conceptually, it is cleanest to apply the filter on the event contents with each update.  At the same time, in the interest of performance, Andy and others have raised the issue of performance penalty if every update has to be subjected to a filter.  One option is for an implementation to simply reject a subscription if there is a chance that it might contain information that would have to be filtered (i.e. do the NACM check at the time the subscription is created), and in case of NACM changes later that might affect subscriptions, to terminate the subscription (and let users resubscribe).

--- Alex

Cc: [email-masked]; [email-masked]; [email-masked]

hi all,

From:Andy Bierman
To:Eric Voit (evoit),

Thanks,
Eric

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 18 Mar 2018 14:53:54 +0100

Hi,

NACM (RFC 8341 by now) should not try to cover all future protocol
mechanisms to access data. NACM has a generic processing model
(section 3.1.3 in RFC 8341) and protocols and implementations must
make sure they follow this model.

If implementations choose to terminate subscriptions since processing
NACM read access rules is considered to be too costly, then they need
to figure out how to do this correctly. This is not something NACM has
to talk about. If at all this is a subscription specific "optimization".

Instead of adding more protocol specific text to NACM, I believe we
should do the opposite, remove protocol specific text from NACM (if
we ever update RFC 8341).

/js

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

---

From: Randy Presuhn <[email-masked]>
Date: Sun, 18 Mar 2018 15:16:17 -0700

Hi -

On 3/18/2018 2:59 AM, [email-masked] wrote:
> Yes.  Conceptually, it is cleanest to apply the filter on the event 
> contents with each update.  At the same time, in the interest of 
> performance, Andy and others have raised the issue of performance 
> penalty if every update has to be subjected to a filter.  One option is 
> for an implementation to simply reject a subscription if there is a 
> chance that it might contain information that would have to be filtered 
> (i.e. do the NACM check at the time the subscription is created), and in 
> case of NACM changes later that might affect subscriptions, to terminate 
> the subscription (and let users resubscribe).

This would increase the cost of NACM configuration changes (probably
not a big deal, but it means hooks between NACM and the notification
subsystem are needed so NACM would be able to let the notification
stuff know it needs to re-evaluate some of its subscriptions) and
would potentially leak information to other users about the fact that
the security administrator is making NACM configuration changes, even
if nothing is happening that would otherwise expose the fact that
the change has taken place.

Randy

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 19 Mar 2018 12:53:51 +0000

About "hooks between NACM...".  That may be possible in a system where NACM rules/processing and subscription handling are integrated (i.e. on the same box), but what if authorization rules are located on a remote TACACS+ or RADIUS server ?

> From: Netconf [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Sunday, March 18, 2018 10:16 PM
> To: [email-masked]
> Subject: Re: [Netconf] [SPAM?] RE: LC on subscribed-notifications-10
> 
> Hi -
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 21 Mar 2018 22:54:08 +0000

Hi Balazs,

All changes listed below should be addressed.  The results can also be seen in...
https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-subscribed-notifications-11.txt 

> From: Netconf <[email-masked]> On Behalf Of Balazs Lengyel
> Sent: Saturday, March 17, 2018 7:01 PM
> To: Kent Watsen <[email-masked]>; [email-masked]
> Subject: Re: [Netconf] LC on subscribed-notifications-10 review
> 
> Hello,
> 
> I  think the document is in a good shape, ready to progress onwards (if my
> MAJOR comments are clarified.).
> 

Notification message definition mechanisms are defined in this document.  But a complete solution requires a transport draft as well.

> Is it stated/documented that at least for netconf the same session must be
> used?

Yes.  Text refined.
 
> So if in Yang-push I subscribe to 2 separate objects, but I only have rights to
> one of them, I will not get notifications when the other changes?

That is YANG push, and that is how it works.   Stream filtering allows access to all or none of an event.
 
> output(subscription-id). This is missing from the Yang Model

Fixed

> P13) It should be stated that delete-subscription MUST always succeed if

Text now says:

If the delete request matches a known subscription established on the same transport session, then it MUST be deleted; otherwise it MUST be rejected with no changes to the publisher.
 
> P15) second list: transport parameter should be mentioned

Fixed.  Put in encoding too.

> P22)
> The publisher may decide to terminate a subscription for any other reason
> too (license expiry, configuration switch, internal error, etc.)

Text updated

> The tree indicates everything as readOnly while a lot of this can be

Fixed
 
> P32) Shouldn't the transport identities be defined in the relevant transport
> drafts/RFCs?

That could be done.   But it would require new yang modules for a single identity.  Seems like overkill to me.

> against the notification.

We took the same path as other YANG documents expressing XPATH or subtree filters.  In any case, filters documented for those examples should work here without change.
 
> message. Is that possible? It should be stated explicitly somewhere.

It is not prohibited.  But have to do this is not defined.  Where it will be defined is notification-messages.

> How is the filter applied in this case?

Before the bundling happens.   The filter is explicitly defined against the event record, and not the bundle.

> messages" IMHO use send instead of get in the first line of the description

Removed group (result of NMDA simplification).  Objects are now in the subscriptions container.
 
> P48) "A list of pre-positioned filters"   use pre-configured or pre-provisioned

Updated.

Thanks again!
Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 22 Mar 2018 00:09:49 +0000

At this point, the process for maintaining synchronization of authorization rules in a distributed  environment is not in the scope of this draft.  It seems like a general topic beyond subscriptions.   

That said, it would be great if a publisher subscribed the authorization rules on the centralized server -> this would result in a push of permission changes as they occur :-).

Eric

> From: Sterne, Jason, March 19, 2018 8:54 AM
> 
> About "hooks between NACM...".  That may be possible in a system where
> NACM rules/processing and subscription handling are integrated (i.e. on the
> same box), but what if authorization rules are located on a remote TACACS+
> or RADIUS server ?
> 
> > > penalty if every update has to be subjected to a filter.  One option
> > > is for an implementation to simply reject a subscription if there is
> > > a chance that it might contain information that would have to be
> > > filtered (i.e. do the NACM check at the time the subscription is
> > > created), and in case of NACM changes later that might affect
> > > subscriptions, to terminate the subscription (and let users resubscribe).
> >
> > if nothing is happening that would otherwise expose the fact that the
> > change has taken place.
> >
> > Randy
> >

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 22 Mar 2018 15:25:19 +0000 (GMT)

Hi,

"Eric Voit (evoit)" <[email-masked]> wrote:
> Notification message definition mechanisms are defined in this
> document.  But a complete solution requires a transport draft as well.

I agree with Balazs.  Shouldn't this sentence be removed?  If not,
where in this document are these delivery mechanmisms defined?

[...]

> We took the same path as other YANG documents expressing XPATH or
> subtree filters.
>
> In any case, filters documented for those examples
> should work here without change.

Can you point to one such example?

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 26 Mar 2018 06:09:34 +0000

> From: Martin Bjorklund, March 22, 2018 11:25 AM
> 
> Hi,
> 
> > https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-
> netcon
> > f-subscribed-notifications-11.txt
> >
> > > I  think the document is in a good shape, ready to progress onwards
> > > (if my MAJOR comments are clarified.).
> > >
> > > Abstract:  "Also defined are delivery mechanisms for instances of
> > > the resulting notification messages."
> I agree with Balazs.  Shouldn't this sentence be removed?  If not, where in
> this document are these delivery mechanmisms defined?

I guess it depends on one's definition of delivery mechanisms.  To avoid all confusion, I reworded to:

This document defines mechanisms and a YANG Data Model enabling subscriber-specific subscriptions to a publisher's event streams.  Applying these elements allows a subscriber to request for and receive a continuous, custom feed of publisher generated information.

Eric

> [...]
> 
> > > P34) There really should be a filter example to show how it is
> > > applied against the notification.
> >
> > In any case, filters documented for those examples should work here
> > without change.
>