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

["Eric Voit (evoit)" <[e-mail]>]

Hi Juergen,

> 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.

Unfortunately using an if-feature does not provide sufficient granularity.
A device can concurrently support multiple TPMs, each potentially having
either TPM1.2 or TPM2 firmware.  The model is trying to ensure that a
specific instance of a TPM can only be configured to use a valid subset of
the allowable algorithms permitted by the type of firmware available.   

Eric

> /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/>