Subject: Re: [Netconf] two-week review of drafts related to notifications and subscriptions

From: Kent Watsen <[email-masked]>
Date: Thu, 19 Oct 2017 02:03:07 +0000

As a contributor, here is my review.  I focused on the three drafts
that the authors have stated a desire to see go to last call:

   o  draft-ietf-netconf-subscribed-notifications
   o  draft-ietf-netconf-yang-push
   o  draft-ietf-netconf-netconf-event-notifications

Note: the below do not represent full reviews.  I was literally 
jumping around and just noticing what caught my eye.  Random
sampling, though I tended to spend a fair amount of time on the
tree diagrams and YANG modules.

draft-ietf-netconf-subscribed-notifications-05
------------------------------------------------------
status: not ready yet.  very complicated (many details).
        flow difficult to read.

* what are "subscription control plane operations bindings"?
* are "pushed event instances" different than the above?
* what is "promise theory based interaction model"?  (reference?)
* I see transport identities for netconf and http2, but why not for restconf too?  (I don't see it defined in restconf-notif-03 either)
* what to do when transport=http2 isn't clear
* Is the "NETCONF" event stream same as in 5277 s3.2.3?
* what is the relationship between streams here and in 5277?
* streams here are identities, unlike "streamNameType" (aka xs:string) in 5077.  Is this an issue?
* use of "<edit-config> operations" for configured subscriptions is confusing.
* the example in s5.1 seems to be more about how to create a configured subscription than establishing a subscription connection 
* Section 7 says "This notification message MAY be encoded as one-way notification element of [RFC5277], Section 4."  If this is a MAY, how does the client know what it received?  And how does the publisher know what format to send?
* xpath-filter is not a feature-based option?
* I see top-level /subscription-config and /subscriptions - is this NMDA compliant?
* for configured subscriptions, how is security established between endpoints?
* for dynamic subscriptions, why is encoding an option, and not inherited from the transport instead?
* having "hints" for what might work better seems complicated...
* are event-notif and restconf-notif Informative references?
* draft-title seems odd

draft-ietf-netconf-yang-push-09
------------------------------------------------------
status: better, but could use a couple clean-up passes

* title: "[Subscribing to] YANG Datastore based Event Notifications"?
* "rapid visibility" - sounds like marketing...
* "On-change subscriptions allow subscribers to subscribe to updates" - it should be "receive updates", right?
* why does s3.5.1 discuss XML/JSON encoding rules?
* dscp, weighting, dependency - are these really needed now?
* s3.9: I have an issue with post-filtering?
* shouldn't 'notifiable-on-change' be metadata?

draft-ietf-netconf-netconf-event-notifications-05
-------------------------------------------------
status: unclear purpose.  mostly seems to be NETCONF-based examples for stuff defined in [subscribe] without any normative text.  I'm unsure we need another draft just for this...

* what is the "the base NETCONF definition"?
* in the examples in s3.1 (and many other sections in the draft), is the xmlns correct? should it be: urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications?  But, more importantly, why is this here at all, shouldn't it be in [subscribe]?
* how often are the examples validated?  - in all the drafts?
* s3.2 - also should be in [subscribe]
* let's not use "data plane" as a term
* There's an "Open Items" section in Appendix A.  The comment should read "(To be removed by Authors prior to Last Call)"  ;)

Also, where is it that the solution relies on the server parsing capability strings from the client's <hello> message?  - I didn't see it this time, but recall discussing it with you before...

Lastly, just skimming these three drafts, I don't yet have a good feeling for how the new [notification-messages] based notification messages are brought in.

Thanks,
Kent // contributor

--

We’d like to direct the WG attention to the set of drafts related to notifications and subscriptions, with the goal of getting a pulse on if the WG thinks they are ready to progress now.

To enable you get an overview and to see how the documents relate to each other, this draft is a good place to start:  https://tools.ietf.org/html/draft-voit-netconf-subscription-and-notif-overview-00.

The drafts related to this review are:
   -  draft-ietf-netconf-subscribed-notifications
   -  draft-ietf-netconf-yang-push
   -  draft-ietf-netconf-netconf-event-notifications
   -  draft-ietf-netconf-restconf-notif
   -  draft-ietf-netconf-notification-messages

While this is not an official WGLC, we will issue one if the response is positive. Please provide comments within two weeks.

Thanks,
Mahesh and Kent

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 19 Oct 2017 23:19:53 +0000

Hi Kent,

Thanks very much for the review.  Thoughts in-line.

BTW: I do appreciate you calling the two week review.  This has worked well.  I have blocked my calendar for the next week so that I can interact (and hopefully incorporate) items as quickly as feasible.   

The good news is that we have had more comments on the drafts in the last week than in the two years since draft adoption, I would love to keep the WG focus here in the coming weeks to close these items.

> From: Kent Watsen, October 18, 2017 10:03 PM
> 
> As a contributor, here is my review.  I focused on the three drafts that the
> authors have stated a desire to see go to last call:
> 
> Note: the below do not represent full reviews.  I was literally jumping around
> and just noticing what caught my eye.  Random sampling, though I tended to
> spend a fair amount of time on the tree diagrams and YANG modules.
> 
> 
> 
> status: not ready yet.  

Hopefully not for long  ;-)

> very complicated (many details).

If there anything you see as unnecessary, or perhaps should be optional?

>         flow difficult to read.

Anything specific?  I am happy to re-order as suggested.
 
> * what are "subscription control plane operations bindings"?

Fixed that based on Martin's comments

> * are "pushed event instances" different than the above?

No.  Also fixed that based on Martin's comments.

> * what is "promise theory based interaction model"?  (reference?)

Yes, I will add the reference.  The best on-line one I know is:
http://markburgess.org/PromiseMethod.pdf 

> * I see transport identities for netconf and http2, but why not for restconf too?
> (I don't see it defined in restconf-notif-03 either)

RESTCONF is not involved with configured subscriptions (see restconf-notif Section 3.1.3 for HTTP2 flow).  So there is no reason for an identity for this purpose.

While is it true that RESTCONF is used for dynamic subscriptions, RESTCONF is never involved with the transport of the one-way notifications.  These always go as a POST on a different TCP connection.   See restconf-notif for 3.1.1 via HTTP2, and 3.1.2 for HTTP1.1.   So it is not necessary to have a RESTCONF identity as a transport for even for operational reporting.

> * what to do when transport=http2 isn't clear

Based on Martin's comments I have added http1.1 as an identity for operational reporting.   Either HTTP1.1 or HTTP2 can be associated with the dynamic subscription established via RESTCONF (as specified in restconf-notif for 3.1.1 via HTTP2, and 3.1.2 for HTTP1.1).

> * Is the "NETCONF" event stream same as in 5277 s3.2.3?

Yes.

And we don't have identities for streams anymore.  So the definition of the NETCONF stream from 5277 s3.2.3 is listed in section 2.1, and the mandatory support for the NETCONF stream when NETCONF transport is used is in notif-netconf section 3.2.   (In the version of subscribed-notifications you read, there was also a steam definition housed in the now nonexistent NETCONF identity description).

> * what is the relationship between streams here and in 5277?

This document doesn't discuss the details of how streams are generated within the publisher like 5277 does.  This detail is not necessary for the external interface definition.

That said,  how to handle/encode names of the streams, the managed objects, the ability to filter, etc. are identical.

> * streams here are identities, unlike "streamNameType" (aka xs:string) in 5077.

Based on Martin's comments that he desires to retain the ability for streams to be spun up possibly during run-time, we have returned to using string for streams (as we did in earlier versions of the draft).   Our switch to identities several months ago was one attempt we made to simplify things, but it didn't work out.    This is an issue and a resolution we have long been anticipating.

> * use of "<edit-config> operations" for configured subscriptions is confusing.

It is just a normal configuration.  I will happily delete the example if you think it unnecessary or redundant.

> * the example in s5.1 seems to be more about how to create a configured
> subscription than establishing a subscription connection

Exactly.  How to establish the subscription connection is transport specific, and therefore in the netconf-notif draft.  Specifically in Section 3.4.3

> * Section 7 says "This notification message MAY be encoded as one-way
> notification element of [RFC5277], Section 4."  If this is a MAY, how does the
> client know what it received?  And how does the publisher know what format
> to send?

I was trying to lay the groundwork for a future support of notification-messages in a way that this document wouldn't have to be updated.  I have given up on that.  Support is now a MUST.  And this will need to be revised in the future when we get notification-messages to an RFC state.

> * xpath-filter is not a feature-based option?

Not feature based.  Of course if the syntax is not supported on a filter, the subscription will be rejected with the error " filter-type-unsupported ".
At this point, I don't recall anyone suggesting xpath should not be a mandatory for event filtering though.  

> * I see top-level /subscription-config and /subscriptions - is this NMDA

As this pre-dates NMDA, we are awaiting the "you MUST make the conversion" directive.  And if this comes, we will gladly do that.

> * for configured subscriptions, how is security established between endpoints?

Via existing mechanisms for secure transport establishment.  E.g., Call home being used for NETCONF as per netconf-notif section 3.4.

> * for dynamic subscriptions, why is encoding an option, and not inherited from

If a RESTCONF establish-subscription and a NETCONF establish-subscription are coming to the same stream name (which under-the-covers is encoded in only one way, and will not be trans-codable) must we reject one of them as unsupportable?  What if you want a push of binary encoded content, must you make that request over a binary transport?  This is supposed to allow variations here.

> * having "hints" for what might work better seems complicated...

In the end, it is necessary.  And not just because people have asked for it:
https://www.ietf.org/mail-archive/web/netconf/current/msg12154.html 

When you get to YANG-Push, there are enough knobs that simply rejecting a subscription without guidance will lead to very poor subscribing client behavior.  The poor behavior will take the form of many unnecessary signaling interactions as subscribers will be making guesses blindly.

> * are event-notif and restconf-notif Informative references?

If you mean netconf-notif, then Yes.  I don't see them being normative, as they don't depend on this document.  Am I missing something?

> * draft-title seems odd

This is a result of history more than anything else.  There are only so many words to go around.  If "Custom Subscription to Event Streams" feels better, I have no issue with the change.

> draft-ietf-netconf-yang-push-09

If we were to change, I think the simpler "Subscribing to YANG datastores" is probably cleaner

> * "rapid visibility" - sounds like marketing...

Will delete "rapid"

> should be "receive updates", right?

Yes, that is cleaner.  Will fix.

> * dscp, weighting, dependency - are these really needed now?

If it were just NETCONF, then no.  But there is real need for congestion management into Telemetry sever receiver clusters.  These clusters are a current choke point.  And head-of-line blocking from queued subscriptions is avoidable when HTTP2 is used.

> * s3.9: I have an issue with post-filtering?

I don't understand.  The sequence of when NACM is applied and when the selection filter is applied is not specified.  Just that the result is the same as with a GET.

> * shouldn't 'notifiable-on-change' be metadata?

Yes.   Is it sufficient just to say this explicitly in section 3.10, or are you looking for something else.

> status: unclear purpose.  mostly seems to be NETCONF-based examples for
> stuff defined in [subscribe] without any normative text.  I'm unsure we need
> another draft just for this...

It is true that most of this is examples.  Examples which we can't place in subscribed-notifications without tying that draft to a specific transport.

That said, there is some normative elements
- use of call home
- timing of the message flows with respect to call home.  (Many reader might assume the correct timing, but we thought it better to be explicit.)
- Required availability of the NETCONF stream
- the making of the NETCONF stream as mandatory.  (For IoT use, there really isn't a reason for the NETCONF stream to be required.)
- how should retries work on a failed configured subscription

> * what is the "the base NETCONF definition"?

Should just be NETCONF RFC 6241.

> * in the examples in s3.1 (and many other sections in the draft), is the xmlns
> correct? should it be: urn:ietf:params:xml:ns:yang:ietf-subscribed-
> notifications?  

I didn't write these, but I did review them.   In my review my belief was that as yang-push imports ietf-yang-push, examples with that namespace should be equally valid.  Am I missing something?

> But, more importantly, why is this here at all, shouldn't it be in
> [subscribe]?

This is an example of a NETCONF get on the steams.  It is probably excessive to have this in either draft.  Section 3.1 can safely be cut out completely.

> * how often are the examples validated?  - in all the drafts?

I defer to Alberto.  I gave an eyeball.

> * s3.2 - also should be in [subscribe]

If IoT devices use subscribed-notifications for pushing SYSLOG extracts, must they support the NETCONF stream?   This is why we felt it better to put it here

> * let's not use "data plane" as a term

Agree.  The three instances of this need to be reworded.

> * There's an "Open Items" section in Appendix A.  The comment should read
> "(To be removed by Authors prior to Last Call)"  ;)

Very true.   All these elements are out-of-scope now, and it can be removed.

> Also, where is it that the solution relies on the server parsing capability strings
> from the client's <hello> message?  - I didn't see it this time, but recall
> discussing it with you before...
> 
> Lastly, just skimming these three drafts, I don't yet have a good feeling for how
> the new [notification-messages] based notification messages are brought in.

At this point, Martin has convinced me that notification-messages should be minimally highlighted so as not to confuse readers prior to its availability.  And that when that works gets done, we make revisions to the three drafts here.

Key items which will get touched here are:

Subscribed-notifications
- update section 7 to use the new notification messages if receiver has indicated support
- update to the establish-subscription RPC so that the subscriber indicates has the option of adding headers

Yang-push
- revision to notifications push-update and push-change-update to use the common headers 

Notif-netconf
- discovery mechanism for the receiver support of the new messaged

Notif-restconf (await the notification-messages draft to publish)
- configured subscriptions and HTTP2 must use the new format
- we probably should just make the format mandatory for the whole draft

Eric

> Thanks,
> Kent // contributor
> 
> 
> --
> 
> We’d like to direct the WG attention to the set of drafts related to notifications
> and subscriptions, with the goal of getting a pulse on if the WG thinks they are
> ready to progress now.
> 
> To enable you get an overview and to see how the documents relate to each
> other, this draft is a good place to start:  https://tools.ietf.org/html/draft-voit-
> netconf-subscription-and-notif-overview-00.
> 
> While this is not an official WGLC, we will issue one if the response is positive.
> Please provide comments within two weeks.
> 
> Thanks,
> Mahesh and Kent
> 
> 
> 
> 
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Fri, 20 Oct 2017 01:51:04 +0000

> If there anything you see as unnecessary, or perhaps should be optional?

The tree diagram is huge.  I understand that much of it is from
grouping expansion, but still, there is a lot to consider (many
details).  I'm just thinking that this is going to take time for
folks to digest fully.

> Anything specific?  I am happy to re-order as suggested.

Also, I'm suspecting that the update from Martin's comments will
get much of this.  It just seemed that every time tried to chase
some bit of information down, it wasn't stated quite right (e.g.,
terminology, phasing, open-endedness, etc.).  All this got in
the way of the readability.

> https://urldefense.proofpoint.com/v2/url?u=http-3A__markburgess.org_PromiseMethod.pdf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=zDualRWvSwyZj8MFPL_XopkywEp9xEJgZXjyhdIBPog&s=Dcx9OsC_ayHR7hbMowWHrtulPtXz20vSvnV2xpEOc0o&e= 

Oh my, that document is 38 pages, I was hoping for simple statement (e.g., the system takes defensive measures in order to ensure resources are available).  I think you have something like this in the yang-push draft.

>> * I see transport identities for netconf and http2, but why not for
>> restconf too? (I don't see it defined in restconf-notif-03 either)
>
> RESTCONF is not involved with configured subscriptions (see 
> restconf-notif Section 3.1.3 for HTTP2 flow).  So there is no
> reason for an identity for this purpose.

I'm not sure if I would say that RESTCONF has no value (in 3.1.3).
Regardless, what transports are or are not available should be
explained in this draft.

> Based on Martin's comments I have added http1.1 as an identity 
> for operational reporting.   Either HTTP1.1 or HTTP2 can be
> associated with the dynamic subscription established via
> RESTCONF (as specified in restconf-notif for 3.1.1 via HTTP2,
> and 3.1.2 for HTTP1.1).

Perhaps update the description clause for the identities with
references to the specific sections in other documents?

>> * Is the "NETCONF" event stream same as in 5277 s3.2.3?

Please say so in the document.

But then it raises the question about having two lists of
streams (5277 and here).  Do they have the same content?
Either way, the document should make this clear.

> And we don't have identities for streams anymore.  So the
> definition of the NETCONF stream from 5277 s3.2.3 is listed
> in section 2.1, and the mandatory support for the NETCONF
> stream when NETCONF transport is used is in notif-netconf
> section 3.2.   (In the version of subscribed-notifications
> you read, there was also a steam definition housed in the
> now nonexistent NETCONF identity description).

I think I need to see the new draft before commenting further.

> This document doesn't discuss the details of how streams are
> generated within the publisher like 5277 does.  This detail
> is not necessary for the external interface definition.
>
> That said, how to handle/encode names of the streams, the 
> managed objects, the ability to filter, etc. are identical.

This document should explain the relationship though, right? (see above)

>> * streams here are identities, unlike "streamNameType"
>> (aka xs:string) in 5077.  Is this an issue?
>
> Based on Martin's comments that he desires to retain the ability
> for streams to be spun up possibly during run-time, we have
> returned to using string for streams (as we did in earlier
> versions of the draft).   Our switch to identities several
> months ago was one attempt we made to simplify things, but
> it didn't work out.    This is an issue and a resolution we
> have long been anticipating.

okay

> It is just a normal configuration.  I will happily delete the
> example if you think it unnecessary or redundant.

No, the examples are good.  It's literally the words "<edit-config> 
operations" are problematic.  Use some other phrasing that is not
NETCONF-specific.

>> * the example in s5.1 seems to be more about how to create a
>> configured subscription than establishing a subscription connection
>
> Exactly.  How to establish the subscription connection is transport
> specific, and therefore in the netconf-notif draft.  Specifically
> in Section 3.4.3

But the section is called "Establishing a Configured Subscription". I
think this actually goes to your use of the word "establish", perhaps
"create" is a better word - "Creating a Configured Subscription" ?

>> * Section 7 says "This notification message MAY be encoded as 
>> one-way notification element of [RFC5277], Section 4."  If this
>> is a MAY, how does the client know what it received?  And how
>> does the publisher know what format to send?
>
> I was trying to lay the groundwork for a future support of 
> notification-messages in a way that this document wouldn't have to
> be updated.  I have given up on that.  Support is now a MUST.  And
> this will need to be revised in the future when we get 
> notification-messages to an RFC state.

okay

> Not feature based.  Of course if the syntax is not supported on
> a filter, the subscription will be rejected with the error
> "filter-type-unsupported ".
>
> At this point, I don't recall anyone suggesting xpath should not
> be a mandatory for event filtering though.  

well, it's not mandatory for NETCONF-based filtering.  So, a system
that doesn't support XPath filtering in NETCONF would have to support
XPath filtering here?

> As this pre-dates NMDA, we are awaiting the "you MUST make the
> conversion" directive.  And if this comes, we will gladly do that.

https://mailarchive.ietf.org/arch/msg/netmod/rqrXUqs8YMIfcrKZnSIoH4gA-8M
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14#section-4.23.3

> Via existing mechanisms for secure transport establishment.  
> E.g., Call home being used for NETCONF as per netconf-notif
> section 3.4.

No, I mean, how is it configured?  Do you need ietf-netconf-server?

>> * for dynamic subscriptions, why is encoding an option, and
>> not inherited from the transport instead?
>
> If a RESTCONF establish-subscription and a NETCONF 
> establish-subscription are coming to the same stream name 
> (which under-the-covers is encoded in only one way, and will
> not be trans-codable) must we reject one of them as unsupportable?
> What if you want a push of binary encoded content, must you
> make that request over a binary transport?  This is supposed
> to allow variations here.

Huh?  I think this is an example of how things get complicated.
I'm sure that there are under-the-covers tricks that can be used
to resolve any ambiguity.

> When you get to YANG-Push, there are enough knobs that simply
> rejecting a subscription without guidance will lead to very
> poor subscribing client behavior.  The poor behavior will take
> the form of many unnecessary signaling interactions as subscribers
> will be making guesses blindly.

It seems complex, and I question implementability...for a server
to make suggestions for how a client can re-issue a subscription
request such that it might succeed.

> If you mean netconf-notif, then Yes.  I don't see them being
> normative, as they don't depend on this document.  Am I missing
> something?

So, first off, you need to fix your I-D referencing convention.
The draft names aren't great, but coming up with different ways
of referring to him just makes it worse.  Please adopt the 
reference anchor format use by the RFC Editor, which is:
"I-D.ietf-netconf-<rest-of-draft-name-here>"

You may when you add the text describing exactly how the various
transport selections are implemented...

>> * draft-title seems odd
>
> This is a result of history more than anything else.  There are 
> only so many words to go around.  If "Custom Subscription to 
> Event Streams" feels better, I have no issue with the change.

My first question is, what's "custom" about it?  Why is the word
"custom" in the title?

> datastores" is probably cleaner

The current title doesn't mean anything to me.   I don't like having
a verb in the title.  Does "YANG Datastore based Event Notifications"
not capture the essence of this draft correctly?

>> * "On-change subscriptions allow subscribers to subscribe to
>> updates" - it should be "receive updates", right?
>

did you skip this one?

>> If it were just NETCONF, then no.  But there is real need 
>> for congestion management into Telemetry sever receiver clusters.
>> These clusters are a current choke point.  And head-of-line
>> blocking from queued subscriptions is avoidable when HTTP2
>> is used.

Perhaps, but I think this is the kind of complexity that is
going to slow down this draft

>> * s3.9: I have an issue with post-filtering
>
> I don't understand.  The sequence of when NACM is applied 
> and when the selection filter is applied is not specified.  
> Just that the result is the same as with a GET.

Access-control should be evaluated at time of subscription
creation (configuration), and then the appropriate filters
are put in place to limit what they select, but having the
system do a per-message access-control test seems like it
would impact performance.

> Yes.   Is it sufficient just to say this explicitly in
> section 3.10, or are you looking for something else.

Define a metadata extension?  (RFC 7952)

>> status: unclear purpose.  mostly seems to be NETCONF-based
>> examples for stuff defined in [subscribe] without any normative
>> text.  I'm unsure we need another draft just for this...
>
> It is true that most of this is examples.  Examples which we
> can't place in subscribed-notifications without tying that
> draft to a specific transport.

I don't know if that's true.  Many data model drafts are intended
for both NETCONF and RESTCONF, and they find ways to have useful
examples that don't tie the draft to a specific transport.

> - timing of the message flows with respect to call home.  (Many
> reader might assume the correct timing, but we thought it better
> to be explicit.)
> - the making of the NETCONF stream as mandatory.  (For IoT use,
> there really isn't a reason for the NETCONF stream to be required.)
>

The examples are getting in the way of the normative parts.  I still
think that these examples likely belong in subscribed-notifications
but, if you keep them here, then maybe move to the Appendix or 
somewhere less distracting?

> Should just be NETCONF RFC 6241.

Please update.

>> * in the examples in s3.1 (and many other sections 
>> in the draft), is the xmlns correct? should it be:
>> urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications?  
>
> I didn't write these, but I did review them.   In my review
> my belief was that as yang-push imports ietf-yang-push, 
> examples with that namespace should be equally valid.  Am 
> I missing something?

The top-level namespace is from subscribed-notifications, only
the nodes augmented by yang-push are in the yang-push namespace.

>> But, more importantly, why is this here at all, shouldn't it
>> be in [subscribe]?
>
> This is an example of a NETCONF get on the steams.  It is 
> probably excessive to have this in either draft.  Section 3.1
> can safely be cut out completely.

It is good/important to have examples that, cumulatively,
cover most of the YANG module.  Think code-coverage - 80%
pretty good.  I'm all for removing unneeded examples, so
long as it doesn't affect mean something aspect (an RPC,
action, notification, configuration, etc.) isn't left out.

> I defer to Alberto.  I gave an eyeball.

My build scripts validate all the examples in a draft every
single time I compile it.  I'm having an issue right now
on one of my drafts validating RESTCONF yang-data based 
examples, but that's more a tooling issue than lack of 
trying.  Please consider integrating example testing into
your build scripts.

> If IoT devices use subscribed-notifications for pushing 
> SYSLOG extracts, must they support the NETCONF stream? 
> This is why we felt it better to put it here

s3.2 regards "Mandatory NETCONF support".  NETCONF servers 
supporting [subscribe] already have to support dynamic
subscriptions (they're not wrapped in a feature statement)
and must support NETCONF stream (I'm assuming 5277 is a
MUST here) and, of course, support the 'running' datastore.

> Agree.  The three instances of this need to be reworded.

thanks

>> * There's an "Open Items" section in Appendix A.  The comment
>> should read "(To be removed by Authors prior to Last Call)"  ;)
>
>

good

>> Also, where is it that the solution relies on the server 
>> parsing capability strings from the client's <hello> message?
>>  - I didn't see it this time, but recall discussing it with
>> you before...

I think you missed this one.

>> Lastly, just skimming these three drafts, I don't yet have a
>> good feeling for how the new [notification-messages] based
>> notification messages are brought in.
> At this point, Martin has convinced me that notification-messages
> should be minimally highlighted so as not to confuse readers
> prior to its availability.  And that when that works gets done,
> we make revisions to the three drafts here.

Okay

Kent // contributor

--

Subscribed-notifications

Yang-push

Notif-netconf

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 20 Oct 2017 04:57:38 +0000

Hi Kent,

> From: Kent Watsen, October 19, 2017 9:51 PM
> 
> The tree diagram is huge.  I understand that much of it is from grouping
> expansion, but still, there is a lot to consider (many details).  I'm just thinking
> that this is going to take time for folks to digest fully.

We really made an attempt to simplify the tree by using a filter-type object instead of the explicit subtyping.  But experienced and capable reviewers argued that explicit subtyping was better.  The result is that we returned to the larger explicitly subtyping a couple weeks ago.  Overall, this added 25% to the tree diagram size :-(.

> Also, I'm suspecting that the update from Martin's comments will get much of
> this.  It just seemed that every time tried to chase some bit of information
> down, it wasn't stated quite right (e.g., terminology, phasing, open-endedness,
> etc.).  All this got in the way of the readability.

Hopefully I got the ones which don't resonate.  My natural ecosystem is deeper in the router, and YANG means I need to use different terms.

> > https://urldefense.proofpoint.com/v2/url?u=http-3A__markburgess.org_Pr
> > omiseMethod.pdf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI
> >
> &r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=zDualRWvSwyZj8MF
> PL_Xo
> >
> pkywEp9xEJgZXjyhdIBPog&s=Dcx9OsC_ayHR7hbMowWHrtulPtXz20vSvnV2xpE
> Oc0o&e
> > =
> 
> Oh my, that document is 38 pages, I was hoping for simple statement (e.g., the
> system takes defensive measures in order to ensure resources are available).  I
> think you have something like this in the yang-push draft.

I can add a simple statement.  Something like "voluntary cooperation between individual, autonomous agents who continuously refine their changing intentions to one another in the form of promises".

> > restconf-notif Section 3.1.3 for HTTP2 flow).  So there is no reason
> > for an identity for this purpose.
> 
> Regardless, what transports are or are not available should be explained in this
> draft.

The transports are listed in the Intro and in Section 1.3.  I can strengthen the wording in 1.3 to point to each transport draft.  Would that work?
 
> > associated with the dynamic subscription established via RESTCONF (as
> > specified in restconf-notif for 3.1.1 via HTTP2, and 3.1.2 for
> > HTTP1.1).
> 
> Perhaps update the description clause for the identities with references to the
> specific sections in other documents?

Will do

> Please say so in the document.

Will do.  

> But then it raises the question about having two lists of streams (5277 and
> here).  Do they have the same content?

Yes

> Either way, the document should make this clear.

Agree.  And ultimately it will be the same stream internally referred to by a common String.

> > And we don't have identities for streams anymore.  So the definition
> > of the NETCONF stream from 5277 s3.2.3 is listed in section 2.1, and
> > the mandatory support for the NETCONF stream when NETCONF transport is
> > used is in notif-netconf
> > you read, there was also a steam definition housed in the now
> > nonexistent NETCONF identity description).
> 
> > This document doesn't discuss the details of how streams are generated
> > within the publisher like 5277 does.  This detail is not necessary for
> > the external interface definition.
> >
> > That said, how to handle/encode names of the streams, the managed
> > objects, the ability to filter, etc. are identical.
> 

Is this necessary in the normative part of the document?  When the notification-messages draft is complete, it will be possible to obsolete RFC-5277 at some later date.  How many linkages are appropriate?   

What I did do in the new version (per Martin's request) is to place in Appendix A: Relationship to RFC-5277.  What I believe we should do is place statements identifying the re-used stream constructs.  Would that work?

> > Based on Martin's comments that he desires to retain the ability for
> > streams to be spun up possibly during run-time, we have returned to
> > using string for streams (as we did in earlier
> > It is just a normal configuration.  I will happily delete the example
> > if you think it unnecessary or redundant.
> 
> No, the examples are good.  It's literally the words "<edit-config> operations"
> are problematic.  Use some other phrasing that is not NETCONF-specific.

I will just use 'configuration operations'

> "create" is a better word - "Creating a Configured Subscription" ?

Will do.  No reason to reuse the establish if it confuses people.

> that doesn't support XPath filtering in NETCONF would have to support

Hmm.  I had been hoping to have at least one (xpath) as mandatory.  But maybe that is unrealistic.

What I am thinking is that maybe both filters should be optional features.  And then specific transport drafts (like NETCONF) can identify them as mandatory. At least when that transport is used.

> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14#section-4.23.3

Yep.  We do fall in the SHOULD category :-)

But seriously, we can convert.  The question is how to do this without losing our place in the review queue.  We had expected to be through WGLC *long* before NMDA was formalized.  And we are very concerned this policy change could result in further delay.  So the current plan we have is to get agreement on the contents of the model.  And then agreement that we have converted what is an acceptable model into an equivalent NMDA version.

> No, I mean, how is it configured?  Do you need ietf-netconf-server?

draft-ietf-netconf-netconf-client-server is absolutely valid and useful in this space.  I see something like that being a recommendation in the implementation considerations rather than the normative text.  Does that make sense?   Or do you see a reason for something normative?  Considering some implementations are overly lax on security requirements as they consider themselves to be in a trusted environment, I have been trying to ensure operators are free to choose specific security practices which might be associated with a transport.

> to resolve any ambiguity.

How about the following examples then.   The NETCONF stream is encoded in XML.  Can RESTCONF *ever* have access to that content via JSON?  What the notification-messages header provides a way to encode that stream's YANG data in JSON per RFC7951?

Or IoT uses XML based establish subscription requests, but receives binary objects as content?

Honestly I don't think we need it for today's implementations.  But we probably will need it for tomorrow's.  If we need to jettison to get through approval, so be it.  I suspect it will be back soon.

> request such that it might succeed.

It really isn't that bad.  For each hint, there is a pretty straight-forward derivation mechanism.  For example, see the rule for hinting at a replay-start-time.

More under-the-covers optimizations are possible, but only will appear over time.

> "I-D.ietf-netconf-<rest-of-draft-name-here>"

Will do.  It is verbose, but we can reflect this at the accepted convention across all documents.

> My first question is, what's "custom" about it?  Why is the word

Custom really means custom filtering on an event stream for a particular subscriber.  (Or put another way, these documents are Sub/Pub rather than Pub/Sub.)   But to convey that succinctly, we quickly exceed any reasonable word count.   Since the beginning we have been fishing for the right words.  And the industry continually evolves.

> not capture the essence of this draft correctly?

Periodic subscriptions don't really have what people think of events (except that a subscriber driven timer has expired).  But if Alex is good, I would say yes to that title.

> >> * why does s3.5.1 discuss XML/JSON encoding rules?

We can probably ditch those two sentences.  Agree Alex?

> going to slow down this draft

It is optional to implement, and matches 1:1 to existing HTTP2 structures.  So I am hoping there is not that much controversial here.   That said, we can revisit this if it becomes a real end-state blocker.

> would impact performance.

Permissions can change.   If you do a GET after your permissions have been reduced, but you subscription feed still provides access, that is a significant security hole.

Yes there are performance implications.  Ways of mitigating some of them are suggested in the document.

> Define a metadata extension?  (RFC 7952)

I didn't think you could put a RFC 7952 annotation on a schema.  Has something changed?  This is why Balazs proposed 
draft-lengyel-netmod-schema-annotation
but no one was interested at the time.

This is why we dumbed things down and went for assignment 'notifiable-on-change' through deviation.  It isn't pretty.  But as we didn't know of an alternative, that is the way things went.

> examples that don't tie the draft to a specific transport.

I guess my can't is a strong word.   The subscribed-notifications document is already big.  Putting more in there doesn't feel helpful.  We should probably talk about what examples could be safely jettisoned.

> somewhere less distracting?

Will ask Alberto about if we can move the bulk of non-normative items to an Appendix.

> > Should just be NETCONF RFC 6241.

Will do.

> the nodes augmented by yang-push are in the yang-push namespace.

Got it.  That will make the examples more verbose.  I will work with Alberto in fixing.

> action, notification, configuration, etc.) isn't left out.

With the use of the Appendices, hopefully we have a useful compromise.

> trying.  Please consider integrating example testing into

Makes sense.

> subscriptions (they're not wrapped in a feature statement)

Yes, we can jettison "dynamic subscriptions" from that statement

> MUST here) and, of course, support the 'running' datastore.

The NETCONF stream is defined in [subscribe] as well.  So I don't think a normative reference to 5277 here is necessary.

> I think you missed this one.

This is only the case for the new notification header.  As we are not using that here yet, it is not needed yet.

> > we make revisions to the three drafts here.

Thanks again Kent.   I know you put some cycles into this, and it is appreciated.

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Oct 2017 14:41:14 +0200 (CEST)

Hi,

Some comments inline.

"Eric Voit (evoit)" <[email-masked]> wrote:
> > grouping
> We really made an attempt to simplify the tree by using a filter-type
> object instead of the explicit subtyping.  But experienced and capable
> reviewers argued that explicit subtyping was better.  The result is
> that we returned to the larger explicitly subtyping a couple weeks
> ago.  Overall, this added 25% to the tree diagram size :-(.

I don't think a big tree in itself necessarily means that the data
model is bad.  However, for readability purposes, you may want to
split the big tree into smaller pieces.  See for example RFC 7404.

> Hopefully I got the ones which don't resonate.  My natural ecosystem
> is deeper in the router, and YANG means I need to use different terms.
> 
> I can add a simple statement.  Something like "voluntary cooperation
> between individual, autonomous agents who continuously refine their
> changing intentions to one another in the form of promises".

Does this really help people to understand this document?

> Is this necessary in the normative part of the document?  When the
> notification-messages draft is complete, it will be possible to
> obsolete RFC-5277 at some later date.  How many linkages are
> appropriate?
> 
> What I did do in the new version (per Martin's request) is to place in
> Appendix A: Relationship to RFC-5277.  What I believe we should do is
> place statements identifying the re-used stream constructs.  Would
> that work?

I think such a section is needed, and I think it shouldn't be an
Appendix, but rather one of the first sections.  This is quite common
in RFCs that updates/obsoletes older RFCs.

> > operations"
> What I am thinking is that maybe both filters should be optional
> features.  And then specific transport drafts (like NETCONF) can
> identify them as mandatory. At least when that transport is used.
> 
> But seriously, we can convert.

Before doing anything, make sure the "subscription-id" issue is
resolved first.  If Rob's proposal is adopted, we will still need two
lists, one config and one operational, even in the NMDA-compliant
version.  Some changes might be needed in the naming of top-level
containers though.

> The question is how to do this without
> losing our place in the review queue.  We had expected to be through
> WGLC *long* before NMDA was formalized.  And we are very concerned
> this policy change could result in further delay.  So the current plan
> we have is to get agreement on the contents of the model.  And then
> agreement that we have converted what is an acceptable model into an
> equivalent NMDA version.

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 23 Oct 2017 13:54:53 +0000

Hi Martin,
Hi Kent,

> From: Martin Bjorklund, October 23, 2017 8:41 AM
> 
> Hi,
> 
> Some comments inline.
> 
> I don't think a big tree in itself necessarily means that the data model is bad.
> However, for readability purposes, you may want to split the big tree into
> smaller pieces.  See for example RFC 7404.

I think you mean RFC 7407?

If many in the WG want such a partitioning, we could do that.    But there are at least three downsides to that approach, at least for this document:

(a) We provide augmentations to this model in yang-push.  Tracking where the augmentations might properly be placed will mean that we still need some base tree structure for the overall model.

(b) For filtering (and for the proposal on receiver transports) the augmentations occur at different levels of the tree.   Therefore tree information will need to be replicated in different figures.  Perhaps we would need convention additions for this?  Note: RFC 7407 didn't seem to have this issue.

(c) It will significantly increase the size of the document.
 
> > > Also, I'm suspecting that the update from Martin's comments will get
> > > much of this.  It just seemed that every time tried to chase some
> > > bit of information down, it wasn't stated quite right (e.g.,
> > > terminology, phasing, open-endedness, etc.).  All this got in the
> > > way of the readability.
> >
> > > Oh my, that document is 38 pages, I was hoping for simple statement
> > > (e.g., the system takes defensive measures in order to ensure
> > > resources are available).  I think you have something like this in
> > > the yang-push draft.
> >

I didn't such an statement helped either.  Which is why I thought a link might be better.   

What I am going to do is include a reference to [yang-push] section 3.4.  This section 3.4 provides the kind of info I think Kent wanted in his simple statement.   In section 3.4, I will also place the link to:
http://markburgess.org/PromiseMethod.pdf

> > > > generated within the publisher like 5277 does.  This detail is not
> > > > necessary for the external interface definition.
> > > >
> I think such a section is needed, and I think it shouldn't be an Appendix, but
> rather one of the first sections.  This is quite common in RFCs that
> updates/obsoletes older RFCs.

The working copy now has this Appendix A:
https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-subscribed-notifications-06.txt

This section easily could be placed as Section 1.4.  The only think needed would be a first sentence of Section 1.4 saying.  "This solution provides enhancements to the subscription model described within RFC-5277.  Key relationships with that document include:"

If Kent and or others in the WG want it moved up, that would be easy to do.

> > > > Exactly.  How to establish the subscription connection is
> > > > transport specific, and therefore in the netconf-notif draft.
> > > > Specifically in Section 3.4.3
> > >
> > > But the section is called "Establishing a Configured Subscription".
> > > I think this actually goes to your use of the word "establish",
> > > perhaps "create" is a better word - "Creating a Configured Subscription" ?
> >
> > > > Not feature based.  Of course if the syntax is not supported on a
> > > > filter, the subscription will be rejected with the error
> > > that doesn't support XPath filtering in NETCONF would have to
> > > support XPath filtering here?
> >
> Before doing anything, make sure the "subscription-id" issue is resolved first.  If
> Rob's proposal is adopted, we will still need two lists, one config and one
> operational, even in the NMDA-compliant version.  Some changes might be
> needed in the naming of top-level containers though.

I will wait.    One thing I just did is add the multiple list need as part of a newly updated:
https://github.com/netconf-wg/rfc5277bis/issues/6 

At this point more people have expressed support for "integer" rather than the other model. 

Eric

> > The question is how to do this without losing our place in the review
> > queue.  We had expected to be through WGLC *long* before NMDA was
> > formalized.  And we are very concerned this policy change could result
> > in further delay.  So the current plan we have is to get agreement on
> > the contents of the model.  And then agreement that we have converted
> > what is an acceptable model into an equivalent NMDA version.
> 
> 
> /martin

---

From: Kent Watsen <[email-masked]>
Date: Mon, 23 Oct 2017 16:29:12 +0000

> I don't think a big tree in itself necessarily means that the data model
> is bad. However, for readability purposes, you may want to split the big
> tree into smaller pieces.  See for example RFC 7404.

To clarify, I don't have an issue with the tree-diagram being large, I was simply observing the fact as a measure of the complexity of the model...

> What I am going to do is include a reference to [yang-push] section 
> 3.4.  This section 3.4 provides the kind of info I think Kent wanted
> in his simple statement.   In section 3.4, I will also place the link
> to: http://markburgess.org/PromiseMethod.pdf

I think Martin's point may have been does this document need to use
the words "promise theory" at all.  Sure, it's a design consideration
that we've taken into account, but the draft just needs to say that
the server will fail the request when it doesn't think it has adequate 
resources - right?

>> Appendix, but rather one of the first sections.  This is quite 
>> common in RFCs that updates/obsoletes older RFCs.

Agreed.  The relationship to RFC 5277 needs to be in the beginning.

> https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-subscribed-notifications-06.txt

FWIW, this is an Oct-16 version of the document...

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Oct 2017 18:31:10 +0200

> the server will fail the request when it doesn't think it has adequate 

Yes, focus on what an implementor needs to know (and leave out
high-level ideas such as Mark's promise theory).

/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: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 23 Oct 2017 17:20:54 +0000

> From: Juergen Schoenwaelder, October 23, 2017 12:31 PM
> 
> Yes, focus on what an implementor needs to know (and leave out high-level
> ideas such as Mark's promise theory).

Fair enough.   I will pull out the promise theory reference in subscribed-notifications.

Eric