[netconf] Mirja Kühlewind's No Objection on draft-ietf-netconf-subscribed-notifications-23: (with COMMENT)

Mirja Kühlewind via Datatracker <noreply@ietf.org> Mon, 29 April 2019 13:51 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 835C612031D; Mon, 29 Apr 2019 06:51:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-netconf-subscribed-notifications@ietf.org, Kent Watsen <kent+ietf@watsen.net>, netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>
Message-ID: <155654586253.15817.17779514484895935501.idtracker@ietfa.amsl.com>
Date: Mon, 29 Apr 2019 06:51:02 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/9sjAONzXXUmHUqYYRj3oZ139G74>
Subject: [netconf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-netconf-subscribed-notifications-23=3A_=28with_COMMENT?= =?utf-8?q?=29?=
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Apr 2019 13:51:03 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-netconf-subscribed-notifications-23: 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:
----------------------------------------------------------------------

 1) Sec 2.3:
   “Where TCP is used, a publisher which supports the "dscp" feature
   SHOULD ensure that a subscription's notification messages are
   returned within a single TCP transport session where all traffic
   shares the subscription's "dscp" leaf value.“
This should probably be generalised to “If a connection-oriented protocol is
used, …”, however, I’m not sure I understand the sentence correctly. It is no
problem to have multiple TCP session using the same DSCP value, however, what
should be avoided is using different DCSP values within the same TCP
connection. Can you please clarify what this sentence is supposed to say?

 2) Also sec 2.3:
“For the "weighting" parameter, when concurrently dequeuing
   notification messages from multiple subscriptions to a receiver, the
   publisher MUST allocate bandwidth to each subscription proportionally
   to the weights assigned to those subscriptions.”
I’m also wondering about this sentence. Should this really be a MUST? I can
assume that there could also be cases where there is a local policy to
prioritise some notification. And do you really mean bandwidth (which would
mean taking the message size into account), or would it make sense to leave the
details to the exact implementation of the publisher and maybe talk just about
“resources” instead?

 3) Sec 1.3 says
“ the loss of the transport session will
      result in the immediate termination of any associated dynamic
      subscriptions.”
However, there is the following text in section 2.4.5:
“The "kill-subscription" operation permits an operator to end a
   dynamic subscription which is not associated with the transport
   session used for the RPC.”
If the subscription is anyway immediately terminated when the transport session
is lost, why is the kill-subscription operation still needed?

 4) Sec 2.5: Please expand VRF.

 5) Figure 8: I would recommend to call the second “evaluate” event
 “re-evaluate” instead.