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

Pierre Francois <pierre.francois.ietf@gmail.com> Tue, 10 November 2020 12:09 UTC

Return-Path: <pierre.francois.ietf@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FCF3A09FC for <netconf@ietfa.amsl.com>; Tue, 10 Nov 2020 04:09:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SuAAVFA1tVT for <netconf@ietfa.amsl.com>; Tue, 10 Nov 2020 04:09:10 -0800 (PST)
Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 210C93A09F6 for <netconf@ietf.org>; Tue, 10 Nov 2020 04:09:10 -0800 (PST)
Received: by mail-ua1-x92d.google.com with SMTP id q68so3853131uaq.3 for <netconf@ietf.org>; Tue, 10 Nov 2020 04:09:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=77cX9arbzNdXkDE8eSlz/0hxBjg/B5jgU66DLYPCzVw=; b=YSFmdFoMvI/NgEtnzaNoJ03nX2HQAjZWARywVHnJZKEjK54E1E6D9X/eMflPfaKDxS IjSIhOA8uTjyJewd/wGLvJbug3hSZpdyHPbmCU7Pd0qXmMvzhzg4qQuZoGESPMyp7i1N ZPJgV11JBKatIZH1OOO17e6st6zm+BLvlOYAnEd7E/2IWcemtYIsi+h8yyUVT4WoKMAu LUk6RKXMoMQNyyv9SApL9bXJ8JZKTecN11S12P7FmOK9Oh2YO2mfY/urYyEvgb271a9e awZP9+hu9B/vDsGfxUTfvYDdsW3t83N5Orbo6V6YdF/8vn1tjzKKsZX/5iy1EOWftYZy wOAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=77cX9arbzNdXkDE8eSlz/0hxBjg/B5jgU66DLYPCzVw=; b=PlhPXtNK+j6sm5DRZbl84n3jhGt3H8RXWtQFlF2meiQRqoycgJJKmY6y6O7ywRDvLA eHposUeTrQijlSGxcIS40OZYcUNFfpHmSkxIrppjQxMwL+537HunLjGo66NYFg+3WOiC p8GMd75k+UW0MmRX0Kq7QADybcYaRvWbfm+uLHjohqU8iEu4+kGYO0CRALcsaEQX/j53 lDuf1Ks2sNfV9ptCXFvwnli09koLGBFhOwT/2dgcp+obw9kMbfzKCp93McrMVxLUUEmN FZYRfihrOWvk6tXbbdVhlIspmlcR0QFXYMOGF4OHt1bHDfv26PSI8D1NJsG9C6p+N4oS Bs3g==
X-Gm-Message-State: AOAM5339d6uRY4g2CmYTL46AAsfn3AQFVOkHykIuO5vymTEIeyJ4e/v2 8iGMlnUJBxWGcUDmB+EUgHvdQyCWNq0o9spMwNQ=
X-Google-Smtp-Source: ABdhPJxGWHykD3vKJmCMOBpWuaOWuq9gMzqr2l1Ce8t09FmQPFS3Ta/syV+znHjP/POpKJJzkVdvp3mddcjtGJdXeoE=
X-Received: by 2002:a9f:2a87:: with SMTP id z7mr4959906uai.133.1605010149077; Tue, 10 Nov 2020 04:09:09 -0800 (PST)
MIME-Version: 1.0
References: <CABCOCHR-K3mdoY=qebmSHe7pDof_i6c75rt4_4Mg00dHR021qA@mail.gmail.com> <646CC099-EEA9-4FAC-BAA4-777BB67D0712@gmail.com>
In-Reply-To: <646CC099-EEA9-4FAC-BAA4-777BB67D0712@gmail.com>
From: Pierre Francois <pierre.francois.ietf@gmail.com>
Date: Tue, 10 Nov 2020 13:08:58 +0100
Message-ID: <CAFNmoOG0Lehn5cwYS2spGG5f3TQsk-cL39mrYeDftdcWYEnCCg@mail.gmail.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Netconf <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cbf49d05b3bf8bd6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/xB9vc4HsOr0z0vYOq7FrQNgdc00>
Subject: Re: [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: Tue, 10 Nov 2020 12:09:12 -0000

Mahesh,

Le mar. 10 nov. 2020 à 03:14, Mahesh Jethanandani <mjethanandani@gmail.com>
a écrit :

> +1 most of these comments.
>

Same :)


> Also please fix all the indentation and max length of 72 in the YANG model.
>

Done. Will be included in the -02.


>
> On Nov 9, 2020, at 9:16 AM, Andy Bierman <andy@yumaworks.com> wrote:
>
> Hi,
>
> 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
> notifications.*
>
>  - The new notification header is very complex, not implemented by anybody,
>    and therefore unproven. The RFC 5277 notification message is widely
> deployed
>    and should be supported.
>
>
> sec 3.2
>
>
> Would suggest that the version field start with a value which is non-zero.
> A zero does not indicate if the value was set or the field was
> uninitialized. Same for ET field.
>

ok.


>
>
>
>
>
> * *  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
>
>
> +1
>
> Is there a method by which the other end will learn the encoding that is
> going to be sent or does the publisher just start sending a given encoding
> whether the other end supports or not? Would suggest that you pick a
> default encoding that both ends have to support, and then come up with a
> method by which the other encodings can be learnt.
>

I think this requires a discussion. During the meeting ok?



>
>
>
>
> *   *  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
> message?
>
>
>
>
> *  *  The Message ID is generated continuously by the sender of UDP-
> Notif messages.  Different subscribers share the same Message ID
> sequence.*
>  - It is not clear why the Message-ID field is present.  This seems to be
> all
>    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 PDU.
>    D) The 2nd sentence is confusing (subscribers?) Maybe you mean that
> different
>       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
> fragmentation
>    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?
>
>
> Andy
>
>
> Section 7
>
> The draft requests a port assignment for UDP notification. Not sure that
> it is needed. The YANG model already defines a way to configure a port, and
> it is mandatory.
>


Agreed.

Thank you,

Pierre.


>
> Thanks.
>
>
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>
>
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>