Re: [netconf] Éric Vyncke's No Objection on draft-ietf-netconf-subscribed-notifications-24: (with COMMENT)

["Eric Voit (evoit)" <[e-mail]>]

Hi Éric, 

Thanks for the comments.  Thoughts in-line...

> From: Éric Vyncke, April 30, 2019 3:00 PM
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-netconf-subscribed-notifications-24: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I appreciate the goal of this document to specify another telemetry streaming
> than gRPC.

Actually this work pre-dates gRPC based Telemetry.  But it took the documents time to get to the IESG. :-)

> As the I-D has been reviewed by YANG-doctors, I did not look in the
> YANG module.
> 
> Comments
> --------
> 
> C1) section 1.3, should the published check authorization before accepting an
> subscription? There is some text in section 3.1 is about authorization but I would
> prefer to have this authorization stated as early as possible

As you found later in the document, the publisher does authorization.  In older versions of this document we did have some of the authorization items up front in the intro.  But found it slowed down the intro of what was already a long document.  So we kept the intro as shorter by pushing that later in the doc.
 
> C2) end of section 1.3, "transport drafts" shouldn't rather be "transport
> specifications" ?

Works for me.  Change made.
 
> C3) end of section 1.3, upon termination decided by the publisher, is there a
> need for any explanation message sent to the subscriber?

Yes, the details on this are laid out as part of the state machines in Section 2.4.1 and 2.5.1.

> C4) is there any reason why the YANG module validation but the datatracker
> fails? Outdated/invalid PYANG ?

Exactly, the YANG validator errors are due to a solved bug in yanglint.    As Kent discusses in his shepherd writeup, the errors clear with new versions of yanglint.
    https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/shepherdwriteup/ 
    
       [SHEPHERD] `pyang` and `yanglint` were used to validate the YANG module 
       defined in this document.  Note that Datatracker shows YANG validation 
       errors, but the module validates fine on my machine (I'm using yanglint
       0.16.110, whereas DataTracker is using yanglint 0.14.80).
    
FYI the bug was fixed in yanglint 0.16.59
https://tools.ietf.org/tools/ietfdb/ticket/2667

> C5) section 2.2 "all event records on an event stream are to be sent", should
> there be a mention of publisher being out of ressource ?

Yes, there are several "out of resource" errors discussed across Section 2.4, 2.5, and in the YANG model.  You do note some of those below.  Again by delaying some of the discussions to later in the document the discussions are less fragmented in places.

> C6) section 2.4.1 "insufficient CPU or bandwidth available" but there may be
> other reasons (e.g. memory), what about using "insufficient CPU, bandwidth
> unavailable or other lack of ressource"

We have been assuming that to little memory is a function of stream's event buffers being exceeded, and that is a function of CPU being insufficient to handle the load from the stream.  So one error seems to cover the case without publisher developers having to make a judgement call on which of these was responsible for the lack of resources.  
 
> C7) for my curiosity, in section 2.4.2.1, how deep could realistically be a replay
> buffer? Minutes?

It could be hours and days for low volume events.   For example, for security cases such as the Integrity Management Architecture (IMA), you might need  to know every IMA related event since boot.
 
> C8) the term 'transport' is used quite often in the document but it seems to refer
> to NETCONF and not so much to my understanding of 'transport' in an IETF
> document (which is TCP, UDP, SCTP, ...). Is it obvious to the readers? If so, then I
> do not mind. Else, it may be useful to clarify in section 1.2

Hopefully it is obvious to the readers.   We went back-and-forth a few years ago on the proper terminology here.   I fear touching the word as touching terminology might induce unforeseeable side-effects.

> Nits
> ----
> 
> N1) is there any reason why not all Cisco authors are not grouped together?
> (even if another one has changed affiliation)

No real reason.  Basically we had an initial order.  And then some authors moved companies, but we kept the order.  If this is an issue for the IESG, we can resequence.

> N2) abstract s/information/data/ also applicable in other sections IMHO

Either works for me honestly.   But so many people had an opinion over the years on this, and we have tweaked this so many times, that I am afraid of making a change here.
 
> N3) section 1.3, expand RPC even if obvious

Done

> N4) section 2.3, expand QoS even if obvious

Done.

Thanks again for the review!

Eric