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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 30 Apr 2019 12:00:11 -0700

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

C2) end of section 1.3, "transport drafts" shouldn't rather be "transport
specifications" ?

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

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

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 ?

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"

C7) for my curiosity, in section 2.4.2.1, how deep could realistically be a
replay buffer? Minutes?

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

Nits
----

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

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

N3) section 1.3, expand RPC even if obvious

N4) section 2.3, expand QoS even if obvious

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 30 Apr 2019 23:29:09 +0000

Hi Éric, 

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

> From: Éric Vyncke, April 30, 2019 3:00 PM
> 
> 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.)
> 
> 
> 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
> --------
> 
> 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

Works for me.  Change made.
 
> 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.

> 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

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

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

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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 1 May 2019 06:35:13 +0000

Éric

Thank you for your replies to my comments. I agree with the replies except on C6 but I am trusting your judgement on this one.

Let's go and do not delay the publication anymore ;-)

-éric

On 01/05/2019, 01:29, "Eric Voit (evoit)" <[email-masked]> wrote:

    Hi Éric,

    

    

    

    

    

    

    

    

    
    Done

    Done.

    Eric