[netconf] Magnus Westerlund's No Objection on draft-ietf-netconf-restconf-notif-13: (with COMMENT)

[Magnus Westerlund via Datatracker <[e-mail]>]

Magnus Westerlund has entered the following ballot position for
draft-ietf-netconf-restconf-notif-13: 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-restconf-notif/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 4:

Based on the QoS discussion for draft-ietf-netconf-subscribed-notifications
weight is not really a a priority in the terms people think of it. It only
provides a weight for bandwidth allocation.

   o  take any existing subscription "priority", as specified by the
      "weighting" leaf node in
      [I-D.draft-ietf-netconf-subscribed-notifications], and copy it
      into the HTTP2 stream weight, [RFC7540] section 5.3, and

I would recommend that the use of "priority" is reformualted here to reflect
that aspect.

   o  take any existing subscription "dependency", as specified by the
      "dependency" leaf node in
      [I-D.draft-ietf-netconf-subscribed-notifications], and use the
      HTTP2 stream for the parent subscription as the HTTP2 stream
      dependency, [RFC7540] section 5.3.1, of the dependent
      subscription.

What is not obivous to me is that just because that a subscription exists at
the publisher that it is going over the same HTTP/2 connection and thus there
might be nothing for the dependency to point at that is relevant for the
mechanism described in RFC 7540. I didn't even find a recommendation that the
receiver (subscriber) should actually re-use the HTTP/2 connection for all
communication with the same publisher.