IETF Logo Mail Archive

Re: [netconf] RESTCONF support in private candidates draft

Kent Watsen <kent+ietf@watsen.net> Thu, 21 March 2024 06:04 UTC

Return-Path: <0100018e5f9c4648-dc5c1890-eb7b-46b8-925a-ec5340d3ef51-000000@amazonses.watsen.net>
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 C7CAEC18DBB3; Wed, 20 Mar 2024 23:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.011
X-Spam-Level:
X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6v-FmO4Z9hIF; Wed, 20 Mar 2024 23:04:22 -0700 (PDT)
Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042BAC18DB9E; Wed, 20 Mar 2024 23:04:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1711001061; h=Content-Type:Content-Transfer-Encoding:From:Mime-Version:Subject:Date:Message-Id:References:Cc:In-Reply-To:To:Feedback-ID; bh=XF96wnl+FreK4wZq+dEs+EVecmdWgBL9CcjZyOLOXtI=; b=dgHnhr9IPiq8brhmmYse9akx5Dj9FtkPLk+p8Fm8TBPnH7hFiOQqZujXRC+iVGVM hQVTW+KOOXoNPj34ss+xdVeN7jcAipWkuH0miRPCkzGSG0RP1pOXyoM4bkCBvsI2i34 X6WqW7OvEF+qk0swwiDXRZ4B+J4gnVd5R+xARF/c=
Content-Type: multipart/alternative; boundary="Apple-Mail-B8F3F3B0-0C5F-49C9-8CB3-DED59D6A8349"
Content-Transfer-Encoding: 7bit
From: Kent Watsen <kent+ietf@watsen.net>
Mime-Version: 1.0 (1.0)
Date: Thu, 21 Mar 2024 06:04:20 +0000
Message-ID: <0100018e5f9c4648-dc5c1890-eb7b-46b8-925a-ec5340d3ef51-000000@email.amazonses.com>
References: <SA1PR08MB72154F5361CAF96E8ABE69BCFF322@SA1PR08MB7215.namprd08.prod.outlook.com>
Cc: Carsten Bormann <cabo@tzi.org>, "Robert Wills (rowills)" <rowills=40cisco.com@dmarc.ietf.org>, core@ietf.org, netconf@ietf.org
In-Reply-To: <SA1PR08MB72154F5361CAF96E8ABE69BCFF322@SA1PR08MB7215.namprd08.prod.outlook.com>
To: "James Cumming (Nokia)" <james.cumming@nokia.com>
X-Mailer: iPhone Mail (21E219)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2024.03.21-54.240.8.33
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Le5_QVZlgZ5DS1bDuovFYbW9WAo>
Subject: Re: [netconf] RESTCONF support in private candidates draft
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 21 Mar 2024 06:04:25 -0000

Knowing what we know now, it makes perfect sense for CORECONF to skip supporting shared-candidate. 

K. 

On Mar 21, 2024, at 2:14 PM, James Cumming (Nokia) <james.cumming@nokia.com> wrote:



Carsten and I had a chance to discuss CORECONF in some more detail during IETF119.  The conclusion of this discussion was that the Private Candidates draft should continue without CORECONF but that CORECONF might well utilize this document in future to deliver candidate configurations in that environment (and they may likely skip shared candidates entirely and just use private candidates).

 

Carsten may well start a small holding draft to explain that CORECONF might use the private candidates draft and some of the fundamental requirements.

 

@Carsten Bormann, please update/clarify this email if/as required.

 

 

 

From: netconf <netconf-bounces@ietf.org> on behalf of Carsten Bormann <cabo@tzi.org>
Date: Monday, 18 March 2024 at 06:58
To: Kent Watsen <kent+ietf@watsen.net>
Cc: Robert Wills (rowills) <rowills=40cisco.com@dmarc.ietf.org>, core@ietf.org <core@ietf.org>, netconf@ietf.org <netconf@ietf.org>
Subject: Re: [netconf] RESTCONF support in private candidates draft

[Some people who received this message don't often get email from cabo@tzi.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification" rel="nofollow">https://aka.ms/LearnAboutSenderIdentification ]

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



On 2024-02-09, at 07:30, Kent Watsen <kent+ietf@watsen.net> wrote:
>
> This is too important to not support in RESTCONF (and CORECONF, I assume).

CORECONF has this simple unified datastore model.

I do believe that creating candidates may make sense as an extension.

Our main concern will then be how to keep a tab on these candidates (e.g., have a clear way how to garbage-collect them, make them work when you only can have a very small number of them).
The concerns should be similar to those discussed here of RESTCONF, except that tying the candidates to client-identities may not work too well (we’d rather model them as resources, I think).

Grüße, Carsten

_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf" rel="nofollow">https://www.ietf.org/mailman/listinfo/netconf

v2.23.0 | Report a Bug | By Email