Re: [netconf] ietf-keystore, truststore, crypto-types

[Balázs Kovács <[e-mail]>]

Hi,





1. Typo



<CODE BEGINS> file "mailto:[e-mail]"



I'd previously found/fixed this in my local copy, but thanks for reporting it.



Ok.



2. Is mandatory true missing from ‘cert’ leaf in ietf-crypto-types?



<snip/>



Possibly, but I don't think so.  For instance, consider asymmetric-key-pair-with-cert-grouping that uses both asymmetric-key-pair-grouping and end-entity-cert-grouping.   One has to create the asymmetric-key prior to being able to execute the generate-certificate-signing-request action to create the end-entity certificate.



That said, this probably is going to raise the question for why then asymmetric-key-pair-grouping nodes are mandatory true, or more generally, if groupings should ever define mandatory true nodes, rather than leave it to the using-schema to refine-in the mandatory true statements if desired.



Ok, I see now, I noticed only the usage in grouping asymmetric-key-pair-with-certs-grouping. But yes, I agree with you that we need to re-consider if groupings should have mandatory true nodes at all.





3. Question: why have the key generation actions been converted to RPCs? If this is because of their earlier containers having now mandatory leaves, then have you considered just moving them one level up, adding ‘name’ as parameter, and keeping them as actions? I’d prefer actions.



Because the requests are no longer bound to an "object".  The RPCs are defined have no effect on either configuration or opstate, they simply return a value that the client will, presumably (especially if encrypted), return back to the device via a standard config update request (e.g, <edit-config>).



FWIW, see "discussion #2" starting on page 12 here https://datatracker.ietf.org/meeting/105/materials/slides-105-netconf-client-server-suite-of-drafts-00.



Why do you prefer actions?



I’d have liked to use actions since I wanted a “datastore effect” to avoid the round-trip drawback of the RPCs. Due to the lack of NMDA implementation and also in general some actions affecting running did not seem an issue for us. But I guess we can always add an extension.



Br,

Balazs