Re: [netconf] Capability-fetching mechanisms

Pierre Francois <> Fri, 23 July 2021 07:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CA583A086D for <>; Fri, 23 Jul 2021 00:26:51 -0700 (PDT)
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 OcfcVDCR1DlZ for <>; Fri, 23 Jul 2021 00:26:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0BADC3A0870 for <>; Fri, 23 Jul 2021 00:26:46 -0700 (PDT)
Received: by with SMTP id k65so861596yba.13 for <>; Fri, 23 Jul 2021 00:26:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3bjc7cwcNnPcX4YixW1fmd1arkpofRvuHAyBqDzceBI=; b=cX7gs6hkZ3dFgNNwbh8wrKAMKW7EZgwlcLpBfDurDJebV/W4q54VtOJBRS5ROFXP4D bc9Nxt0PktbnM3XaO0DQzqT2qrJj0c/51/qLsCsaOXZcQXLx7gjcqlWHPrnoDVoIuCI1 kN4JBTsM33l1gF5p7P9hsUwFD3QW0vfIrbdUxb3TNl4dsqmH0j7fbEz1+I57fKaFjcP3 X38li3Lyv9cJFRy9Jm3kV/2dlMJOcw1S4fhK09JU7nmO/8oaFpV5QnCpYJ79UG5cHls5 tfApVODOof3VoZmQTAWfZD2gAoWLM+DVJl3hAJbzEGc78Q97UM+l64lf5Xivb1a8gMkc xroQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3bjc7cwcNnPcX4YixW1fmd1arkpofRvuHAyBqDzceBI=; b=ub/U7IosTq+d3gmRwpWpiL+mFyW+QW/RLUA9uFZaDgdbdOtV75OImYqWHw9hm05zUx wWHfkxm+CNdv5ert5aQESrq13xq/ak2dZ9YhiUo8syW+TEgUc+2PIhEU++RQisYhJ1Pa Vm8+RIqX9JTSvEOvkaEkCelAL4bsUxqcR6fVKSplVeiFJO0fK+eCcwq/OHIRfhapWfxC RGW95MKBmqpwKIIqn9OwRGgmMf+YiokepPT511dJV8UUqtDGTtuTEgQKe4i1c+lZfuW0 meNoHR7Hk82b2ZFRQXhCCgEYQ+t8bONXg2/avJv8w3A5yzcoTdVayLJp97BtdzGel1WT KOdw==
X-Gm-Message-State: AOAM531g/w3ZdSYlHsj56JiPQxATxGEYXnCWZfESM4a1R5z9ozhyVFFv O6jQj8MLoiNz8eNAAj82oklB2OjhBMj9OrelaR4=
X-Google-Smtp-Source: ABdhPJzn3tUo4Bro4+VwXNN31Lo41A+xFahU1nwmudEt/4MAgreBysIkLAxSMM3DBJvzNKZSwgHoy0Rr0d0dSJ1h05Y=
X-Received: by 2002:a25:bc10:: with SMTP id i16mr4648379ybh.73.1627025205757; Fri, 23 Jul 2021 00:26:45 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Pierre Francois <>
Date: Fri, 23 Jul 2021 09:26:36 +0200
Message-ID: <>
To: Mahesh Jethanandani <>
Cc: Kent Watsen <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000006e081d05c7c553e5"
Archived-At: <>
Subject: Re: [netconf] Capability-fetching mechanisms
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: Fri, 23 Jul 2021 07:26:52 -0000


Le jeu. 22 juil. 2021 à 20:05, Mahesh Jethanandani <>
a écrit :

> Hi Pierre,
> On Jul 22, 2021, at 4:43 AM, Pierre Francois <
>> wrote:
> Kent,
> (ii)                I wasn’t sure why you used inet:uri’s for the
>> capabilities rather than YANG identities.  I guess that this would be a bit
>> more work because it would require both an IANA maintained registry of
>> capabilities and also a derived IANA registry of YANG identities that would
>> be automatically updated by IANA whenever a new capability is added to the
>> registry.  E.g., following the approach for say for iana-routing-types
>> YANG Module
>> <>
>> I’m unsure if the use of identities was ever discussed.  It seems
>> reasonable and, if not mistaken, would NOT require an IANA registry of any
>> sort…as the identities (on the wire) would be scoped by their modules.
>> The only “downside” is the “overhead” introduce for custom (non-standard)
>> capabilities, but it doesn’t seem meaningful relative to getting IANA out
>> of having to maintain a registry of any kind.
> Transposing this discussion to our udp-notif, for the sake of consistency,
> is the WG considering not to create IANA pools for the protocol code points
> defining options and encoding types?
> Are we saying NETCONF no longer uses IANA to organize their protocol code
> points? I have no strong opinion on this, as our goal as developers is to
> have the IETF tell us which values to use for these codes,
> but this seems like a radical change of approach compared to what I've
> been used to, so I'd like to make sure I understand this is what is going
> on ;)
> The proposal, as I understand from Rob is to use identities to define
> capabilities. For example, a new module called
> “iana-notif-transport-capabilities” would define a base identity called:
>   identity transport-capabilities {
>     description
>       "Base identity from which identities describing transport
>        capabilities are derived.";
>   }
> Other capabilities would then derive of this base identity to define new
> capabilities. See attached module for a more complete example.
> This module will be a IANA maintained module. However, the difference is
> that while the module will be registered with IANA, you do not need a
> registry to maintain the capabilities. Instead, anybody can create a new
> module, import the base identity from this IANA module, and define a new
> capability.
> Makes sense?

For expressing capabilities, it seems to work, but the pools I was
referring to and discussing with you offline are for what I will find on
the wire for options and encoding types in the header.
For this to work I'd need the values explicited in the module so that I
know what to put in the code.
If anybody can create their own and decide which value will be on the wire
without a pool, we lose unicity, don't we?