Re: [netconf] Capability-fetching mechanisms

Pierre Francois <> Thu, 22 July 2021 11:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17FFB3A433E for <>; Thu, 22 Jul 2021 04:43:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 N14btHBi3FLe for <>; Thu, 22 Jul 2021 04:43:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DEA343A42B6 for <>; Thu, 22 Jul 2021 04:43:47 -0700 (PDT)
Received: by with SMTP id r135so4846535ybc.0 for <>; Thu, 22 Jul 2021 04:43:47 -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=Vw4B9CnQKesjiFP5aYC2eh5AXJtt7rGYZ2MnLiCCjSo=; b=AxHjOmhpV9fWk4VlzkbqyavXGp4/EJ6+elUVSwfKcqQNr42TEm5u3cJUn95dS3sYzP Vh+WAUJnf0lXxuFSHdzr+jVwX2SgdEl5GSgmdf99sZXi2iThlnE9GDjHuTQ5UjZrpiwS Olw7qLB/bAGq3CuRESHOgWnlrvOJ+KL7PZ1q5QhhvvErDgJtwRZQBQk31rRXYedAorhy nujZuljfSU1SYIYwWDDJ4otKdw0yJjwqXI/vMrJpK24zWyDOFYErJjCCVV8czl6Ygy3T fJ9YUlU9jVzMuJI4TIM3bUQZ6FskszEHr0bY1/X5G3m7WQFsZDIukuy3gpRBaRnTXeho 8TIw==
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=Vw4B9CnQKesjiFP5aYC2eh5AXJtt7rGYZ2MnLiCCjSo=; b=tPB+PrP3jTu8vt0T8zISG6c7v7051ujLmhB9nNAYj+7WLUEIlY4cvX68KcJjRrTyva a/+CoKPyyWO4jN8YmgyotTlL5i/4DniOyNx05H66R7CLpnZMo6sZvSs/ZE/dOCMao8yR 99i6l3TQ+PJhWGlEeFfSNB3NUqnMsJ/5/7Kk03jwe0DAQ1KkQvhLzfmIpmwn2T6FZ0eU 9mu0LqQ3tzvnQawr6mAQrl9xTyUv9Od7XFKrHWC9lFF2gA8OKCOrmXIcgmEIM1e5ojl/ UX40IY4T+T1qgfv9z8U8qKGAUuaARFHOqj1jp+S21XaVlj4nb68lnNA6rzuWJMWOm9j0 5qDA==
X-Gm-Message-State: AOAM530YTzOTu4BZISEmUi7qc5n/av/KLsR1suAYAPDVNit0+VLia3UC +mkoXvyiCJlLAU6ROSQ9rNfFwtk/b6NAzDmFzlgNw1m27FM=
X-Google-Smtp-Source: ABdhPJzAQeE/hsb0fA8E4qXxMAFPrErEqdsM2M5e338tTPFbmL4Tj55JrCYB0DHJDiS3Q093Phaqlp6KI3YJldqGsNY=
X-Received: by 2002:a25:8b8b:: with SMTP id j11mr50970990ybl.138.1626954226686; Thu, 22 Jul 2021 04:43:46 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Pierre Francois <>
Date: Thu, 22 Jul 2021 13:43:36 +0200
Message-ID: <>
To: Kent Watsen <>
Cc: "maqiufang (A)" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000bf5cd905c7b4cc65"
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 11:43:54 -0000


(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 ;)