Re: [netconf] Capability-fetching mechanisms

Mahesh Jethanandani <> Thu, 22 July 2021 18:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD85A3A0C04 for <>; Thu, 22 Jul 2021 11:05:07 -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 Y10LEYGkLu2P for <>; Thu, 22 Jul 2021 11:05:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 762683A0C02 for <>; Thu, 22 Jul 2021 11:05:02 -0700 (PDT)
Received: by with SMTP id c15so5444313pls.13 for <>; Thu, 22 Jul 2021 11:05:02 -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=lDuSmWLhHDo3VWHwTZFf3OxLChsfER04xSePJ3FfxhA=; b=bkpd7zUK9ELr+epSTvy4I1mXe1/K6CLCSjHECOkNvCbZPALRJs8uZSXhxn3i0foVcb QMUsC8WXZYfyNW12n4KLtR4wJmrekVd0716pKy84nxuvAoPeoTlAXkNBnlDs9wcFBHdj DjSpj7jVOzGEGLsDEJNCEnZFrGo+exbXMs9WX6ClXj8eLmwcKB8WD+h1EPvwCRo2MiGa JTLY3gMTj4zZkEZ64+lRSqZAVUNEeVKz1v0jsdRC2rPULdnZoEMfUz5Hd4ePZ+FkLL05 DwVunlq1sY1thGt7NVztXfcO2WqdW76JI8rjJKOAsNDCi8L55SlP2oLH2sErovgbdcgt bB0w==
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=lDuSmWLhHDo3VWHwTZFf3OxLChsfER04xSePJ3FfxhA=; b=UnBXdJR2Flpq4ZOtJG78nrTqJy7leSnCk3EhZ/s6ccGv3GU0cw8EAk+klFLWMwzxYN NZByzrRqlfh1V0WxHOw+IvAP2aOpSUDq1ePghhGkWnyVCgsW5DOsGKQ5MUcsuaMC2qkA qD4Npdu3ILO45qLXEWZqVhMIeUhMzBaOopXSgpezHFAnCRFYvtkr+xUR0hfFKuIwJYJR 1LyeAnlc6+jfOkgPBUXCQNytAGguSW1U5DNKSZBufBJ0/6FiMWYgaD5dBXAeB64SfQTg H2JWpPp3Hwe+HszwHHBMWx05qKDsBmfm3dT6M0Fh5lc+JBwliEzrSKJp2OlgJJqnmpo1 O/BA==
X-Gm-Message-State: AOAM532CFe8HYNnogj1bRfdzIddM9gRoQVgLTainH1fMLqbbxbqeg4ue 9B7MYkFG2s/Zhm9gF35I0pc=
X-Google-Smtp-Source: ABdhPJzpnBC3zeehRgg/ZnUmljLvoNZg4m5WJ1PRN+ClOosi7dOuLyDmAX3oSxOFNJoHGUnUGmdsiQ==
X-Received: by 2002:a05:6a00:1895:b029:32c:b091:ebc with SMTP id x21-20020a056a001895b029032cb0910ebcmr1030476pfh.4.1626977101002; Thu, 22 Jul 2021 11:05:01 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id g2sm26418583pjt.51.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Jul 2021 11:04:59 -0700 (PDT)
From: Mahesh Jethanandani <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_106A8D68-8CFE-4970-A943-B88ECC676AA0"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Thu, 22 Jul 2021 11:04:49 -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: Thu, 22 Jul 2021 18:05:08 -0000

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 {
      "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?

> Regards, 
> Pierre.
> _______________________________________________
> netconf mailing list

Mahesh Jethanandani