Re: [Rats] do not address yang warnings by making nodes writable

[Juergen Schoenwaelder <[e-mail]>]

On Fri, Mar 05, 2021 at 03:42:54PM +0000, Eric Voit (evoit) wrote:
> Hi Juergen,
> 
> Where you say "this config applies to TPMs version X", we are accomplishing
> a similar function via when statements,  E.g.:
> 
>         uses TPM12-hash-algo {
>           when "tpm-firmware-version = 'taa:tpm12'";
> 
> It is possible to place what is currently within these 'when' statement to
> instead be within the descriptions.  But using 'when' statements seemed a
> more robust approach.

Except you had a broken config true node.
 
> Based on our discussion, I can adjust that description of "leaf
> tpm-firmware-version" to:     "Identifies the cryptoprocessor API set
> supported.  This is automatically configured by the device and should not be
> changed."   This will eliminate the earlier text about a YANG warning and
> NMDA.  Is this a reasonable approach?

Overwriting YANG semantics is not what you want. Perhaps you actually
want to use a YANG feature to make parts of the model conditional to a
feature indicating different TPM versions. Of, you already have an
if-feature. It might well be that I do not understand what you are
trying to achieve.

/js

> Thanks,
> Eric
> 
> > -----Original Message-----
> > From: Juergen Schoenwaelder <[e-mail]>
> > Sent: Friday, March 5, 2021 6:12 AM
> > To: Eric Voit (evoit) <[e-mail]>
> > Cc: Michael Richardson <[e-mail]>; [e-mail]
> > Subject: Re: [Rats] do not address yang warnings by making nodes writable
> > 
> > Eric,
> > 
> > I think you want to configure that "this config applies to TPMs version
> X", i.e.,
> > you configure the version that needs to match the TPMs version so that
> your
> > config can apply, you are of course not configuring the TPM's version
> (that
> > would require a TPM configuration model but as you write, for many TPMs
> this
> > will be by design not configurable).
> > 
> > For network interfaces, we do the same: You write down the configuration
> of a
> > network interface and we expect that the configuration only gets applied
> if a
> > matching network interface is actually present. (This is basically where
> the
> > difference between intended configuration and applied configuration comes
> > into play.)
> > 
> > /js
> > 
> > On Fri, Feb 19, 2021 at 04:35:32PM +0000, Eric Voit (evoit) wrote:
> > > Hi Juergen,
> > >
> > > > From: Juergen Schoenwaelder, February 19, 2021 11:01 AM
> > > >
> > > > I do not know what the purpose of the MUST statements is since I did
> > > > not
> > > dig
> > > > deeper but it could be that config is only applied to TPMs where the
> > > configured
> > > > version matches the version of the TPM. This would then require to
> > > configure
> > > > the version, much like we allow to provision interface configs even
> > > > if
> > > there is
> > > > (currently) no matching interfaces.
> > > >
> > > > It could also be that the WG does not want to allow something to be
> > > configured
> > > > for a TPM version that does (currently) not exist. Even in that
> > > > case, you
> > > would
> > > > have to convey the TPM version as part of the config and then have
> > > > logic defined in description statements that such config snippets
> > > > are to be
> > > rejected
> > > > (instead of being not applied).
> > >
> > > This is closer to the purpose.
> > >
> > > The TPM is a hardware device* which will follow an API defined in
> another
> > > standards body.   The TPM has firmware which will not be configured
> through
> > > YANG model.  It is conceivable that new TPM firmware versions will be
> > > exposed, so ENUMs cannot be used.   It is this firmware version which
> will
> > > allow other relevant configuration operations to be applied.
> > >
> > > So you cannot change the configuration datastore for this object (as it
> is
> > > read internally).   But you also can't make the object as "config
> false", as
> > > other configurable items depend on it.  If there is a proper way to
> > > document such a relationship, it would be great to update the model so
> that
> > the
> > > relationship does not require the text currently in the description.
> Any
> > > suggestions?
> > >
> > > * There are also such things as Virtual TPMs.  This model is intending
> > > to frame YANG structures which can be reused should others want to build
> for
> > > these as well.   But that is out-of-scope here.
> > >
> > > Thanks,
> > > Eric
> > >
> > > > My point is that saying a leaf is rw config, it is expected to be
> > > > used for validation, but it is not expected to be there is not
> working.
> > > >
> > > > Personally, I prefer config that can be provisioned but may not be
> > > > applied
> > > if it
> > > > does not match the resources (currently) available.
> > > > Yes, this requires to check for possible differences between applied
> > > > and provisioned (aka running) config but the opposite gets you into
> > > > situation
> > > where a
> > > > hardware component failures leads to an invalid config and you are
> > > > either bricked or in a mode hard to understand.
> > > >
> > > > /js
> > > >
> > > > On Fri, Feb 19, 2021 at 09:36:40AM -0500, Michael Richardson wrote:
> > > > >
> > > > > Juergen Schoenwaelder <[e-mail]> wrote:
> > > > >     > I doubt that this is a proper solution as you now have to
> > > configure the
> > > > >     > tpm-firmware-version. If you cannot configure this (as the
> > > description
> > > > >     > says), then the MUST may always be false, i.e, once you
> > > > > implement
> > > this,
> > > > >     > you will see that this does not work.
> > > > >
> > > > > I am not clueful about XPATH forcing "rw"... is there another
> solution?
> > > > >
> > > > > --
> > > > > Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
> consulting
> > > )
> > > > >            Sandelman Software Works Inc, Ottawa and Worldwide
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > > > Fax:   [phone]         <https://www.jacobs-university.de/>
> > > >
> > > > _______________________________________________
> > > > RATS mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/rats
> > 
> > 
> > 
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/>



-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>