Re: [netconf] Capability-fetching mechanisms

Mahesh Jethanandani <> Sat, 24 July 2021 20:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 684803A083B for <>; Sat, 24 Jul 2021 13:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.096
X-Spam-Status: No, score=-1.096 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mpIm2XiKcBOh for <>; Sat, 24 Jul 2021 13:08:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30A243A0848 for <>; Sat, 24 Jul 2021 13:08:36 -0700 (PDT)
Received: by with SMTP id n10so7175252plf.4 for <>; Sat, 24 Jul 2021 13:08:36 -0700 (PDT)
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=sIrxg6gMYDHMngjFH+bejIZK5h+8VSnFDGyrCjgseO8=; b=ieZ6IKfDkyiKjXPq9AZywAu9Fsga+fdWsZMtXQeWtuvu34toxZbKjrCw2Tf9CDOpcG 0gowZn6/Yp7Jh9F+bI5aG6nmPSwNwzKNSuI0fg4TrPfAiMcZYmcW78g/uE4PZ9+cOSxj vJXBqB4EL6iuhxTRfoTNSbeZ0dcn7+qjvyWaMoSuzk7U2ecXiEoa5DCg6YWrIzY3ZeRF U1JiIqIpEa1YnaCkSsH9wzZ3zqGSfCyUZer1mzongSMDrjxVYt/y0S14g8REDK3zJFCA 3mfmHcCl3fWD80wo3eqsdP7EYwF9py6iihf2aEHLsXWXLfwtThvYhSob3EraJc4WJOBe gp5Q==
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=sIrxg6gMYDHMngjFH+bejIZK5h+8VSnFDGyrCjgseO8=; b=FgJsUD7jwmlBzH9aLrE2iU45LtoM+EVwbxVYMQ/RKTgMggjZK+ON9bQ6UEG1eVIcab rzL0RkkJ7O6TKSF4h1CVfGK+yIHQHlAoiKTky2fYbASJdqCVvB1AYVP7H/1ENhEVenP4 7ICXCDqWqPeGD6Ws/T1ZtHZzUwHUbwFfSAiWIWFcBngT4UQYt2+XOb2dg8WfyEYxcgwK 4b079Bs10uubA8nP3M0wgpnWLTaqvG0zccPuLk93yId5id0WZv0V1ecZbIFZ4i1/EIWm xysvzEMB8MPddCM4XZNWCvinCwLdiN4zlBThivDX6C9jDXKgaH7TuO0N6z6OYwQyWGdI mrhA==
X-Gm-Message-State: AOAM530CeYLaNPBFR61Fj3Z4XRNNAeEHu2QozHsXnmB3XKyON6VjKBow MKXtiPG9JLJ6k5f/9gHPAmk=
X-Google-Smtp-Source: ABdhPJx3GvdnE02WRdHjxNAArepTJxsmM7lks8r6j+ZGwFiw/VHqKtaVsslj+h0BfzCns4NNtvR39w==
X-Received: by 2002:a63:1913:: with SMTP id z19mr10618770pgl.315.1627157314966; Sat, 24 Jul 2021 13:08:34 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id u2sm37640488pfh.61.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jul 2021 13:08:34 -0700 (PDT)
From: Mahesh Jethanandani <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9A76FCBB-635D-48AD-879D-96881B1EEC54"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Sat, 24 Jul 2021 13:08:33 -0700
In-Reply-To: <>
Cc: Kent Watsen <>, "" <>
To: Pierre Francois <>
References: <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
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: Sat, 24 Jul 2021 20:08:41 -0000

Hi Pierre,

> On Jul 23, 2021, at 12:26 AM, Pierre Francois <> wrote:
> Mahesh, 
> 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?

You will notice that the thread starts with Rob’s message in the green, where he was specifically asking about capability advertisement. And so does my response. So this solution works for capabilities, but will not address the question you raise about code points. For that you might have to make a IANA registry request.

HTC. Thanks.

> Regards, 
> Pierre.

Mahesh Jethanandani