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

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Thu, 16 May 2019 04:47:11 -0700

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.

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 21 May 2019 16:03:43 +0000

Hi,

Thank you for the review. Please see inline.

On 2019-05-16, 7:47 AM, "Magnus Westerlund via Datatracker" <[email-masked]> wrote:

    
    
    Section 4:

    
    I would recommend that the use of "priority" is reformualted here to reflect
    that aspect.
<RR> We got similar comments from another reviewer, the proposed new text for the next revision is:
take 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 ...
Would this address your comment?

    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.
 <RR> Good point, this is not spelled out.  We will add text for the subscriber's reuse of the HTTP2 session:
for dynamic subscriptions to a specific publisher, all subscriber URI GET requests MUST use a common HTTP2 session for a particular DSCP value.

Regards,
Reshad.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 22 May 2019 07:43:50 +0000

>     https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/

Yes, that is at least actionable.

> for dynamic subscriptions to a specific publisher, all subscriber URI GET requests MUST use a common HTTP2 session for a particular DSCP value.

Is that really a MUST? I would understand a RECOMMENDED to enable the
dependency and weighting within the subscription using the same DSCP.
However, what are the reasons to mandate it, and I don't believe it is
enforceable as the publisher can't determine that a receiver is the same
instance as another receiver, at least not if I assume that the
receivers are instances running in a virtualized environment.

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 22 May 2019 21:40:52 +0000

Hi,

On 2019-05-22, 3:44 AM, "Magnus Westerlund" <[email-masked]> wrote:

    
    Is that really a MUST? I would understand a RECOMMENDED to enable the
    dependency and weighting within the subscription using the same DSCP.
    However, what are the reasons to mandate it, and I don't believe it is
    enforceable as the publisher can't determine that a receiver is the same
    instance as another receiver, at least not if I assume that the
    receivers are instances running in a virtualized environment.
<RR2> You are correct. What about:
for dynamic subscriptions to a specific publisher, it is recommended that all subscriber URI GET requests use a common HTTP2 session for a particular DSCP value.

Regards,
Reshad.
    
    Cheers
    
    Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 May 2019 07:59:52 +0000

Hi,

>     >     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
>     >     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
>     > for dynamic subscriptions to a specific publisher, all subscriber URI 
> GET
> requests MUST use a common HTTP2 session for a particular DSCP value.
>
> for dynamic subscriptions to a specific publisher, it is recommended that 
> all
> subscriber URI GET requests use a common HTTP2 session for a particular
> DSCP value.

If you are rewriting the old sentence that had a MUST because different DSCP 
needs different TCP connections as only a single DSCP can be applied per TCP 
connection, I think you need to have these two issues separated. One for 
stating the recommendation about reusing HTTP/2 sessions for multiple 
subscriptions using the same DSCP value. A second one stating the requirement 
that you need to use different HTTP/2 sessions for each DSCP value in use.

Cheers

Magnus Westerlund

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 23 May 2019 21:45:16 +0000

Hi,

On 2019-05-23, 4:00 AM, "Magnus Westerlund" <[email-masked]> wrote:

    Hi,

The text above was indeed for reusing HTTP2 sessions on the client/subscriber. I'll add text for the last part above too (different DSCP values can't share HTTP2 session).

Regards,
Reshad.

    Cheers
    
    Magnus Westerlund