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

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

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.

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?

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