[netconf] comments on draft-ietf-netconf-udp-notif-01

Andy Bierman <andy@yumaworks.com> Mon, 09 November 2020 17:17 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 084983A1242 for <netconf@ietfa.amsl.com>; Mon, 9 Nov 2020 09:17:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id gYHjreiBEJku for <netconf@ietfa.amsl.com>; Mon, 9 Nov 2020 09:17:02 -0800 (PST)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67FA73A1139 for <netconf@ietf.org>; Mon, 9 Nov 2020 09:17:02 -0800 (PST)
Received: by mail-lj1-x22a.google.com with SMTP id 11so11304426ljf.2 for <netconf@ietf.org>; Mon, 09 Nov 2020 09:17:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ngrk5jmge4dSmZQC5p+uhnRYDMcIdu3oBAp1sRJTQPY=; b=OD225KEY8PxexVx9C/LNNmnZ1qEfYH1bc2bYhVWX5iUFPg0svbFEivUNPD4AJZFnQI BAi3JJSMlKt1O1x8SONBRn0etXOVQuoVnzn8xSWeJ75fmlOr0hZI6Kq2SqpOmeHWEKXD zV6F0/tknyQcVAOYZPikXw2Qh2ShH5O/qtT4maMqiuyqJ8yuWqz6OQqEkiroSfIiPHNd I6HAtLTtUZ+jqYOz2fJWc+zpjUNc4qeTFz12vfv9cnlAA2GwUT3HucukUtOy132dhnsZ hTcT9g7UuOHRn16E0YIkPsRkr1mI9nFVfwFaCxQk34lfciWpTty35yx75feoC1A6mg3V ma7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ngrk5jmge4dSmZQC5p+uhnRYDMcIdu3oBAp1sRJTQPY=; b=k8iTtSrq7JqcZevwM6xcIq4cZOO+l+rYkE66NnZI58RAAYEBbYTNpOAO8cVf16yDmY 0pddNUs7iuQlTU3s/uQPOKkeSuRiWMIhYUnm/VYmfRIG310ub9s62g4n//uztrabi3E4 /B1MHF1vR18oRnzNxNXN8szpGE7K6xiSvd9wyDquyjW7YQ2qSBEF9njRKqnUzyr/+uqg vnl8IIef8fkR61quS+U/IHaN24JrW7XUWNNM0gffB465Hu5yLH5Ho2PV8+rc9bL2P7SH ZreNEucUKaC0edWYpT9vlbNn7mULhbUiyn4R+28feFTIgl0jzentTZ0NXbtmOYBI2nbr VIzQ==
X-Gm-Message-State: AOAM530gzjkwae4tHjvRf51ZICmV9JzWX5nMrtMVGGkLeCz6jQHQfFjU fC/Y/wYWZe3BALOyajvbmeQS6+9z8UdIjZnoO9NOcDoGKj3rGg==
X-Google-Smtp-Source: ABdhPJz+1qgPB/Snoc9k54l53bvg8nwE+uyZ5KiV4zbF0XyzrEAhoM7CG9Zqd2eKomYcmMJ1+AHvoM0dwWrdJ4qZyFo=
X-Received: by 2002:a2e:a54c:: with SMTP id e12mr2731002ljn.220.1604942220222; Mon, 09 Nov 2020 09:17:00 -0800 (PST)
MIME-Version: 1.0
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 09 Nov 2020 09:16:49 -0800
Message-ID: <CABCOCHR-K3mdoY=qebmSHe7pDof_i6c75rt4_4Mg00dHR021qA@mail.gmail.com>
To: Netconf <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ebff6105b3afba7f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/DP6quVa0ADM06qlQS-rz1SUDORM>
Subject: [netconf] comments on draft-ietf-netconf-udp-notif-01
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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, 09 Nov 2020 17:17:04 -0000


I have some comments and questions about this draft.

sec 3.1:

*      [I-D.ietf-netconf-notification-messages] describes the structure
  of the Notification Message for single notifications and bundled

 - The new notification header is very complex, not implemented by anybody,
   and therefore unproven. The RFC 5277 notification message is widely
   and should be supported.

sec 3.2

* *  S represents the space of encoding type specified in the ET field.
  When S is unset, ET represents the standard encoding types as
defined in this document.  When S is set, ET represents a private
space to be freely used for non standard encodings.*
 - This new "S bit" payload encoding is not interoperable
    A) different vendors can pick whatever values they want for the ET field
    B) There is no reliable way to identify the vendor (or publisher
software details)
    in this protocol

*   *  Observation-Domain-ID is a 32-bit identifier of the Observation
Domain that led to the production of the notification message, as
defined in [I-D.ietf-netconf-notification-messages]. *

 - Why is this field needed if it is already in the new notification

*  *  The Message ID is generated continuously by the sender of UDP-
Notif messages.  Different subscribers share the same Message ID
 - It is not clear why the Message-ID field is present.  This seems to be
   the text about it.  The field is OK, but needs clarification

   A) What is the receiver supposed to do to validate a Message-ID?
      This implies that some state is maintained by the receiver
   B) Does this field increment by 1 for every message? Or increment by 1
      for every message from the same Observation-Domain-ID?
   C) How is this field used if the Segmentation Option is used?
      Suggest: all multi-PDU messages MUST have the same Message-ID in each
   D) The 2nd sentence is confusing (subscribers?) Maybe you mean that
      subscriptions supported by the same Observation-Domain-ID share
      the same Message-ID

sec 3.3.1:

*   An implementation of this specification MUST NOT rely on IP
 fragmentation by default to carry large messages.  An implementation   of
this specification MUST either restrict the size of individual   messages
carried over this protocol, or support the segmentation   option.*

 - This appears to be the only normative text about the application-level
   and reassembly procedures.
   A) Is the sender required to finish a multi-PDU message (i.e. send
      segment 0 through N, in order) before sending a different Message-ID?
   B) Is it legal to use the option if only 1 segment is sent (i.e., L bit
      set for Segment 0)
   C) Is it illegal to send any more segments for the same Message-ID after
      the L bit has been sent?