> The fact that a draft has been adopted by a WG does not mean it will
> get finished and published as a standard. I have seen documents dying,
> I have seen entire WGs dying.
Sure, okay, and funny.
> So do the client/server/crypto/... configuration modules need any
> special handling by the s
The fact that a draft has been adopted by a WG does not mean it will
get finished and published as a standard. I have seen documents dying,
I have seen entire WGs dying.
So do the client/server/crypto/... configuration modules need any
special handling by the server or not? If the answer is no, we
> Perhaps Kent can help us by summarizing why he believes copying is
> needed, i.e., why lazy references by name do not work for credentials
> stored in TPMs.
The truststore and keystore use-case entails the following concepts from
the system-config draft:
- Inactive Until Referenced
https
[...]
> Question 6: Copying TPM keys into :running
>
> This thread started with the realization that "the requirement of copying
> keys [and] certificates into running doesn't seem ideal". Clearly, copying
> things from TPMs into running is a nuisance for clients, a usability problem
> (what
Hi,
This is becoming a long thread, and it is already recurring theme. It is a
quite interesting and perhaps necessary discussion, but I think a summary of
the questions at hand is in order.
Question 1: Data store validity according to current RFCs
Some of the debate concerns what current RFC
On Tue, Mar 28, 2023 at 2:37 PM Kent Watsen wrote:
> Hi Andy,
>
> No customer would ever let us take away this tenet, no matter what RFC
> comes out.
>
>
> What tenet? That is valid or that the representation returned
> to clients is valid?
>
both. But I think the expectation is for non-NMDA s
Hi Andy,
> No customer would ever let us take away this tenet, no matter what RFC comes
> out.
What tenet? That is valid or that the representation returned to
clients is valid?
No one is talking about (on the server) not being valid, the only
nuance is
in *how* the server validates , whic
r, and we should also think
> carefully about the text and perhaps examples in the truststore/keystore
> drafts (since they currently state that the keys/certificates must be
> copied into , and I think that we are saying with NMDA that this
> is not required).
>
> Thanks,
> Rob
>
standing?
Best Regards,
Qiufang
-Original Message-
From: Jürgen Schönwälder
Sent: Monday, March 27, 2023 2:13 PM
To: Jan Lindblad
Cc: Rob Wilton (rwilton) ;
draft-ietf-netmod-system-con...@ietf.org; Kent Watsen ;
netmod@ietf.org
Subject: Re: [netmod] system configuration/datastore an
8:01 AM
To: Jürgen Schönwälder ;
draft-ietf-netmod-system-con...@ietf.org; Kent Watsen
Cc: netmod@ietf.org
Subject: RE: [netmod] system configuration/datastore and the
keystore/truststore drafts
Hi Jürgen, Kent,
If we can take that interpretation (and I agree I think that was the spirit of
On Mon, Mar 27, 2023 at 04:04:34AM +0200, Jan Lindblad wrote:
> Rob, Jürgen, Kent, WG,
>
> I am strongly opposed to giving up the idea that running must always be
> valid. This is one of the landmark properties that has made NETCONF the most
> useful management interface for network automation
> to clarify the expected behaviour, and we should also think carefully about
> the text and perhaps examples in the truststore/keystore drafts (since they
> currently state that the keys/certificates must be copied into , and
> I think that we are saying with NMDA that this is not
> Cc: netmod@ietf.org
> Subject: Re: [netmod] system configuration/datastore and the
> keystore/truststore drafts
>
> Rob,
>
> my reading of Figure 2 of RFC 8342 is that validation happens on
> intended and not on running. I assume the system config is folded in
>
This is my reading as well. Despite being published 5 years ago, the pushback
comes because there’s no *programmatic* way to prevent client breakage. There
is a need to have a mechanism, like the “critical” flag (1), to signal when new
behavior is required.
(1) https://github.com/netmod-wg/
Rob,
my reading of Figure 2 of RFC 8342 is that validation happens on
intended and not on running. I assume the system config is folded in
between running and intended. This seems to be inline with the
approach taken by the system config draft. This, of course, leaves is
open what actually happens
Hi,
I'm in the process of AD reviewing Kent's keystore and truststore drafts in
NETCONF.
In both of these drafts, there is a desire to be able to use keys or
certificates that are managed on the device, potentially as part of a TPM, and
yet be able to reference those keys/certificates from the
16 matches
Mail list logo
