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

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 19 Feb 2021 14:11:22 +0100

Hi,

I have seen this in draft-ietf-rats-yang-tpm-charra-05.txt:

        leaf tpm-firmware-version {
          type identityref {
            base taa:cryptoprocessor;
          }
          mandatory true;
          description
            "Identifies the cryptoprocessor API set supported.  This
            cannot be configured.  However it is referenced via XPATH
            as part of configuration, so is shown as 'rw'
            to eliminate YANG warnings related NMDA.";
	}

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.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 19 Feb 2021 09:36:40 -0500

Juergen Schoenwaelder <[email-masked]> 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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 19 Feb 2021 17:01:03 +0100

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

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 19 Feb 2021 16:35:32 +0000

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.
>
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
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats