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

[Éric Vyncke via Datatracker <[e-mail]>]

É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