Re: [netconf] Capability-fetching mechanisms
Pierre Francois <pierre.francois.ietf@gmail.com> Sat, 24 July 2021 22:08 UTC
Return-Path: <pierre.francois.ietf@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F049E3A0538 for <netconf@ietfa.amsl.com>; Sat, 24 Jul 2021 15:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uM-1qWHo5JC for <netconf@ietfa.amsl.com>; Sat, 24 Jul 2021 15:08:26 -0700 (PDT)
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E3F3A0529 for <netconf@ietf.org>; Sat, 24 Jul 2021 15:08:26 -0700 (PDT)
Received: by mail-yb1-xb30.google.com with SMTP id k65so3676069yba.13 for <netconf@ietf.org>; Sat, 24 Jul 2021 15:08:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5blkFhPGTR3bpAE9ROrGN7xsBeSsPmWKuTjjsYBiIEI=; b=c6cDxyb9T/tSRamIJpq9121p1VjFkS/GYqHCe+h9iB65iej7ZXgn86J/uRoRCA4vVR u2DFBVmJjtcBWjAoA1jtX9mmujqSsaG0UjujvcUKI/ctW57E3bTmFxcFpmsVLekY+EYt ZkrAOOlbiRTwvkiisju+jZVAxIlgBJIBI03FjKfz+uuVhejn01UDUgy7ssBkK21MAp4k JNZm2S+jaJOc88ZqHGd6XUqlCCsdBhp+Vel4jjp0FUTVFZr99g4VIhteHHWMpsr9/UqT zhj6I1FeGOGlNk9xzTu5jsXG4mZRtaKt5NY7lyXVYN9ACptkitUFLDsv9matPoEaz0vk PsLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5blkFhPGTR3bpAE9ROrGN7xsBeSsPmWKuTjjsYBiIEI=; b=VS7/C1KXEK2Ax9HZpUBV9fSYA55ApbnfzrZNCyKg0UdAKLeqr5XDcFxr4GaHwvtdNM ST+wWW1VMRDOhHb44i8k1CW3JILgVRjNqMMHGnXlSDsg+SgIMLMs6euYn3rVZbmYfkRi PbKwFc+78XvliRlHED//xQ51HVKetWUBMWaRVCsv2AYi8A48quHnX2jP6khgizn7MaJC IGSh0S0tgfJ9nGZ+Kltq0YephKG58V+dJgRhz+o2i8yJa67ov2XiZvmpthOv8pmNYhXE W5OHIRTdgXkLh8DB+zm72Kn9tNJG8SnO6iDMIyW4M73665mJibINbK0RbjmYS2GCucL4 ERwA==
X-Gm-Message-State: AOAM530Qu1mnGGHuEIzrDlL+GyiFbUnBft5sp+2p/W0yiVsWTGq2Qnhg lLedi6PEbJ5P7Cq3TKBh0WQuEsyKvbyZTke3ql0RXPfACOE=
X-Google-Smtp-Source: ABdhPJy2CLeRcKju76HzGT/6evifx8Nr7+kfCbE47u2SHwygmoHq5kD2PHNKX8vW/WOGaHHg6Evi6AEsBgm64nvVyTk=
X-Received: by 2002:a25:744c:: with SMTP id p73mr14027024ybc.507.1627164505599; Sat, 24 Jul 2021 15:08:25 -0700 (PDT)
MIME-Version: 1.0
References: <7527caa444da49d5bce2608512c668df@huawei.com> <741DCE37-211F-4AA0-B023-D1D551D93E13@gmail.com> <63f192192a3f4750ac9e6dddeb8145e5@huawei.com> <DM4PR11MB5438DFE51C5038B2452FA425B5E19@DM4PR11MB5438.namprd11.prod.outlook.com> <3ade922f804b4f6d8a657318ebd5058f@huawei.com> <0100017ac4c24615-714693f5-47a3-4df0-96ff-f23432c34f2a-000000@email.amazonses.com> <CAFNmoOFXPo1d-citT3J7+1+9XOBhtNiS_HR4uq4sp_pVPaNzkw@mail.gmail.com> <6F54F86F-87E1-433A-8142-220CD2BEE73E@gmail.com> <CAFNmoOF=T+3OaozypJnX9CJV=xVj3APULmZOtMX=6YRiX8a2Nw@mail.gmail.com> <040453BC-C7DA-4701-B80A-834ECA350D52@gmail.com>
In-Reply-To: <040453BC-C7DA-4701-B80A-834ECA350D52@gmail.com>
From: Pierre Francois <pierre.francois.ietf@gmail.com>
Date: Sun, 25 Jul 2021 00:08:14 +0200
Message-ID: <CAFNmoOHuocrux-wE0EaJOV+XBm0umeCLojYvVUSK-sXYnTK+qw@mail.gmail.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Kent Watsen <kent+ietf@watsen.net>, "netconf@ietf.org" <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000058f36305c7e5c24c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/3qARqdNExP9CoCN8oexighKWbAA>
Subject: Re: [netconf] Capability-fetching mechanisms
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Jul 2021 22:08:31 -0000
Hello Mahesh, That's what I thought initially. I just followed the suggestion I received from you to react to this thread when I mentioned the creation of these pools planned for -04. All is well then. If the wg agrees I'll add the IANA requests to the next revision of the draft. Thanks ! Cheers, Pierre. Le sam. 24 juil. 2021 à 22:08, Mahesh Jethanandani <mjethanandani@gmail.com> a écrit : > Hi Pierre, > > On Jul 23, 2021, at 12:26 AM, Pierre Francois < > pierre.francois.ietf@gmail.com> wrote: > > Mahesh, > > Le jeu. 22 juil. 2021 à 20:05, Mahesh Jethanandani < > mjethanandani@gmail.com> a écrit : > >> Hi Pierre, >> >> On Jul 22, 2021, at 4:43 AM, Pierre Francois < >> pierre.francois.ietf@gmail.com> 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 >>> <https://www.iana.org/assignments/iana-routing-types/iana-routing-types.xhtml> >>> >>> >>> 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 > mjethanandani@gmail.com > > > > > >
- [netconf] Capability-fetching mechanisms Kent Watsen
- Re: [netconf] Capability-fetching mechanisms Kent Watsen
- Re: [netconf] Capability-fetching mechanisms Qin Wu
- Re: [netconf] Capability-fetching mechanisms Wei Wang
- Re: [netconf] Capability-fetching mechanisms maqiufang (A)
- Re: [netconf] Capability-fetching mechanisms Mahesh Jethanandani
- Re: [netconf] Capability-fetching mechanisms Qin Wu
- Re: [netconf] Capability-fetching mechanisms Mahesh Jethanandani
- Re: [netconf] Capability-fetching mechanisms Kent Watsen
- Re: [netconf] Capability-fetching mechanisms Qin Wu
- Re: [netconf] Capability-fetching mechanisms maqiufang (A)
- Re: [netconf] Capability-fetching mechanisms Mahesh Jethanandani
- Re: [netconf] Capability-fetching mechanisms Kent Watsen
- [netconf] 答复: Capability-fetching mechanisms Qin Wu
- Re: [netconf] Capability-fetching mechanisms Zmail
- Re: [netconf] Capability-fetching mechanisms Qin Wu
- Re: [netconf] Capability-fetching mechanisms maqiufang (A)
- Re: [netconf] Capability-fetching mechanisms Kent Watsen
- Re: [netconf] Capability-fetching mechanisms Qin Wu
- Re: [netconf] Capability-fetching mechanisms Mahesh Jethanandani
- Re: [netconf] Capability-fetching mechanisms maqiufang (A)
- Re: [netconf] Capability-fetching mechanisms Rob Wilton (rwilton)
- Re: [netconf] Capability-fetching mechanisms maqiufang (A)
- Re: [netconf] Capability-fetching mechanisms Kent Watsen
- Re: [netconf] Capability-fetching mechanisms Pierre Francois
- Re: [netconf] Capability-fetching mechanisms Mahesh Jethanandani
- Re: [netconf] Capability-fetching mechanisms Pierre Francois
- Re: [netconf] Capability-fetching mechanisms Mahesh Jethanandani
- Re: [netconf] Capability-fetching mechanisms Pierre Francois
- Re: [netconf] Capability-fetching mechanisms Rob Wilton (rwilton)