[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: Mirja Kühlewind 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: Mirja Kühlewind <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] Mirja Kühlewind's No Objection on draft-ietf-netconf-subscribed-notifications-23: (with COMMENT)
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.
- [netconf] Mirja Kühlewind's No Objection on draft… Mirja Kühlewind via Datatracker