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

Mahesh Jethanandani <> Tue, 10 November 2020 02:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B3C0E3A1598 for <>; Mon, 9 Nov 2020 18:14:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EnEit3TSKlBU for <>; Mon, 9 Nov 2020 18:14:18 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09E803A1311 for <>; Mon, 9 Nov 2020 18:14:18 -0800 (PST)
Received: by with SMTP id r10so8789773pgb.10 for <>; Mon, 09 Nov 2020 18:14:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=wMqicCkkVzxw3rpVI3po48Plie2lvej0zAK27Fa0xvQ=; b=mVu8pnFkCav7SZA1UX3gzeCDeqN+ExFQQdK0cav12ooY6ChbU891OEXy9Te8IEbuI5 /YNeZMbZnXS+8apnlyDuAOcl8k9GAlX0uw44xZUIDBeB9WKXUdExX9K6s4ESAUFsKC8b vn1TyCXpSzWkclSFiTUH2FGlZnNIIs/HuAOjU0hI8oEOvhSkoSvaE2yo58c2xFDl24ZT 1T7CTFE+n19bVOCs03UrFtOo5zz/0MYH4L6nuw/MAxjhAsMHnUK1HNrKtVRQTTyYsv22 g+LP0MYNuAChAoUpQNV/egkZDx7Pf2Z/w1YxLi4pd5JRqW/9TuZWeSyYRUc3RocsZmxz Q7WA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=wMqicCkkVzxw3rpVI3po48Plie2lvej0zAK27Fa0xvQ=; b=rz39XeZOAVDTS7pZWoaQF546p4pCq1Yr/Tej+QIYcKl3G/XPYmAfHs/MPXAMe565K+ k0noMVZjBvD4RNRSsmHIB0mnD0B+wE7n7wY08eA7VdkI5RI9GnIGwtD6wErw2omBHYD/ S0XEqUXruTCiZUWqfM5wmh8iu9H4mX4dzS+byIRK+6Tgmro3z5ZBODVXKM4IfDQvh0Tj jVnKpmPZJh2t3TNoA53I2VgaoUVOaisi9JTLdYYLaijUu90O1kzOmo1uWT7vZCe0SoqI 92kHOC4fu8kSxh0eLlhklBiwvnINumdK7GUXJJeOCAPWJxeLYqDQP8SlBqHtn1ecPQV7 kCPA==
X-Gm-Message-State: AOAM530bcvmRuwtEN7fXT+hSJ+hvojrSXkwIAbUL1GVvNwszNsHXIYcD rZNxIvkN/irpIb7bkceQQ5QorZkLkDo=
X-Google-Smtp-Source: ABdhPJzdfFWtUdJCZvayk4SqDpcucyQfbb76qLw1bT/G6ENNywlmt/uWaiK7nw6489qKOpphSPK+6g==
X-Received: by 2002:a17:90a:f492:: with SMTP id bx18mr194782pjb.123.1604974456961; Mon, 09 Nov 2020 18:14:16 -0800 (PST)
Received: from ?IPv6:2601:647:5600:5020:4533:862b:a684:b838? ([2601:647:5600:5020:4533:862b:a684:b838]) by with ESMTPSA id f16sm10878494pgk.48.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Nov 2020 18:14:16 -0800 (PST)
From: Mahesh Jethanandani <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7D919344-61C8-402A-9EC2-025834E246B3"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Mon, 09 Nov 2020 18:14:14 -0800
In-Reply-To: <>
To: Netconf <>
References: <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [netconf] comments on draft-ietf-netconf-udp-notif-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Nov 2020 02:14:20 -0000

+1 most of these comments. Also please fix all the indentation and max length of 72 in the YANG model.

> On Nov 9, 2020, at 9:16 AM, Andy Bierman <> 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.

>    *  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


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.

>    *  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.


> _______________________________________________
> netconf mailing list

Mahesh Jethanandani