path: root/vnfs/TestVNF/netconftemplates/netconftemplates/ietf-keystore@2016-10-31.yin

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-1">
  <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;module name="ietf-keystore"
        xmlns="urn:ietf:params:xml:ns:yang:yin:1"
        xmlns:ks="urn:ietf:params:xml:ns:yang:ietf-keystore"
        xmlns:yang="urn:ietf:params:xml:ns:yang:ietf-yang-types"&gt;
  &lt;yang-version value="1.1"/&gt;
  &lt;namespace uri="urn:ietf:params:xml:ns:yang:ietf-keystore"/&gt;
  &lt;prefix value="ks"/&gt;
  &lt;import module="ietf-yang-types"&gt;
    &lt;prefix value="yang"/&gt;
    &lt;reference&gt;
      &lt;text&gt;RFC 6991: Common YANG Data Types&lt;/text&gt;
    &lt;/reference&gt;
  &lt;/import&gt;
  &lt;organization&gt;
    &lt;text&gt;IETF NETCONF (Network Configuration) Working Group&lt;/text&gt;
  &lt;/organization&gt;
  &lt;contact&gt;
    &lt;text&gt;WG Web:   &amp;lt;http://tools.ietf.org/wg/netconf/&amp;gt;
WG List:  &amp;lt;mailto:netconf@ietf.org&amp;gt;

WG Chair: Mehmet Ersue
          &amp;lt;mailto:mehmet.ersue@nsn.com&amp;gt;

WG Chair: Mahesh Jethanandani
          &amp;lt;mailto:mjethanandani@gmail.com&amp;gt;

Editor:   Kent Watsen
          &amp;lt;mailto:kwatsen@juniper.net&amp;gt;&lt;/text&gt;
  &lt;/contact&gt;
  &lt;description&gt;
    &lt;text&gt;This module defines a keystore to centralize management of
security credentials.

Copyright (c) 2014 IETF Trust and the persons identified as
authors of the code. All rights reserved.

Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).

This version of this YANG module is part of RFC VVVV; see
the RFC itself for full legal notices.&lt;/text&gt;
  &lt;/description&gt;
  &lt;revision date="2016-10-31"&gt;
    &lt;description&gt;
      &lt;text&gt;Initial version&lt;/text&gt;
    &lt;/description&gt;
    &lt;reference&gt;
      &lt;text&gt;RFC VVVV: NETCONF Server and RESTCONF Server Configuration
          Models&lt;/text&gt;
    &lt;/reference&gt;
  &lt;/revision&gt;
  &lt;identity name="key-algorithm"&gt;
    &lt;description&gt;
      &lt;text&gt;Base identity from which all key-algorithms are derived.&lt;/text&gt;
    &lt;/description&gt;
  &lt;/identity&gt;
  &lt;identity name="rsa"&gt;
    &lt;base name="key-algorithm"/&gt;
    &lt;description&gt;
      &lt;text&gt;The RSA algorithm.&lt;/text&gt;
    &lt;/description&gt;
    &lt;reference&gt;
      &lt;text&gt;RFC3447: Public-Key Cryptography Standards (PKCS) #1:
         RSA Cryptography Specifications Version 2.1.&lt;/text&gt;
    &lt;/reference&gt;
  &lt;/identity&gt;
  &lt;identity name="secp192r1"&gt;
    &lt;base name="key-algorithm"/&gt;
    &lt;description&gt;
      &lt;text&gt;The secp192r1 algorithm.&lt;/text&gt;
    &lt;/description&gt;
    &lt;reference&gt;
      &lt;text&gt;RFC5480:
  Elliptic Curve Cryptography Subject Public Key Information.&lt;/text&gt;
    &lt;/reference&gt;
  &lt;/identity&gt;
  &lt;identity name="secp256r1"&gt;
    &lt;base name="key-algorithm"/&gt;
    &lt;description&gt;
      &lt;text&gt;The secp256r1 algorithm.&lt;/text&gt;
    &lt;/description&gt;
    &lt;reference&gt;
      &lt;text&gt;RFC5480:
  Elliptic Curve Cryptography Subject Public Key Information.&lt;/text&gt;
    &lt;/reference&gt;
  &lt;/identity&gt;
  &lt;identity name="secp384r1"&gt;
    &lt;base name="key-algorithm"/&gt;
    &lt;description&gt;
      &lt;text&gt;The secp384r1 algorithm.&lt;/text&gt;
    &lt;/description&gt;
    &lt;reference&gt;
      &lt;text&gt;RFC5480:
  Elliptic Curve Cryptography Subject Public Key Information.&lt;/text&gt;
    &lt;/reference&gt;
  &lt;/identity&gt;
  &lt;identity name="secp521r1"&gt;
    &lt;base name="key-algorithm"/&gt;
    &lt;description&gt;
      &lt;text&gt;The secp521r1 algorithm.&lt;/text&gt;
    &lt;/description&gt;
    &lt;reference&gt;
      &lt;text&gt;RFC5480:
  Elliptic Curve Cryptography Subject Public Key Information.&lt;/text&gt;
    &lt;/reference&gt;
  &lt;/identity&gt;
  &lt;container name="keystore"&gt;
    &lt;description&gt;
      &lt;text&gt;A list of private-keys and their associated certificates, as
well as lists of trusted certificates for client certificate
authentication.  RPCs are provided to generate a new private
key and to generate a certificate signing requests.&lt;/text&gt;
    &lt;/description&gt;
    &lt;container name="private-keys"&gt;
      &lt;description&gt;
        &lt;text&gt;A list of private key maintained by the keystore.&lt;/text&gt;
      &lt;/description&gt;
      &lt;list name="private-key"&gt;
        &lt;key value="name"/&gt;
        &lt;description&gt;
          &lt;text&gt;A private key.&lt;/text&gt;
        &lt;/description&gt;
        &lt;leaf name="name"&gt;
          &lt;type name="string"/&gt;
          &lt;description&gt;
            &lt;text&gt;An arbitrary name for the private key.&lt;/text&gt;
          &lt;/description&gt;
        &lt;/leaf&gt;
        &lt;leaf name="algorithm"&gt;
          &lt;type name="identityref"&gt;
            &lt;base name="key-algorithm"/&gt;
          &lt;/type&gt;
          &lt;config value="false"/&gt;
          &lt;description&gt;
            &lt;text&gt;The algorithm used by the private key.&lt;/text&gt;
          &lt;/description&gt;
        &lt;/leaf&gt;
        &lt;leaf name="key-length"&gt;
          &lt;type name="uint32"/&gt;
          &lt;config value="false"/&gt;
          &lt;description&gt;
            &lt;text&gt;The key-length used by the private key.&lt;/text&gt;
          &lt;/description&gt;
        &lt;/leaf&gt;
        &lt;leaf name="public-key"&gt;
          &lt;type name="binary"/&gt;
          &lt;config value="false"/&gt;
          &lt;mandatory value="true"/&gt;
          &lt;description&gt;
            &lt;text&gt;An OneAsymmetricKey 'publicKey' structure as specified
by RFC 5958, Section 2 encoded using the ASN.1
distinguished encoding rules (DER), as specified
in ITU-T X.690.&lt;/text&gt;
          &lt;/description&gt;
          &lt;reference&gt;
            &lt;text&gt;RFC 5958:
   Asymmetric Key Packages
ITU-T X.690:
   Information technology - ASN.1 encoding rules:
   Specification of Basic Encoding Rules (BER),
   Canonical Encoding Rules (CER) and Distinguished
   Encoding Rules (DER).&lt;/text&gt;
          &lt;/reference&gt;
        &lt;/leaf&gt;
        &lt;container name="certificate-chains"&gt;
          &lt;description&gt;
            &lt;text&gt;Certificate chains associated with this private key.
More than one chain per key is enabled to support,
for instance, a TPM-protected key that has associated
both IDevID and LDevID certificates.&lt;/text&gt;
          &lt;/description&gt;
          &lt;list name="certificate-chain"&gt;
            &lt;key value="name"/&gt;
            &lt;description&gt;
              &lt;text&gt;A certificate chain for this public key.&lt;/text&gt;
            &lt;/description&gt;
            &lt;leaf name="name"&gt;
              &lt;type name="string"/&gt;
              &lt;description&gt;
                &lt;text&gt;An arbitrary name for the certificate chain.  The
name must be a unique across all private keys, not
just within this private key.&lt;/text&gt;
              &lt;/description&gt;
            &lt;/leaf&gt;
            &lt;leaf-list name="certificate"&gt;
              &lt;type name="binary"/&gt;
              &lt;ordered-by value="user"/&gt;
              &lt;description&gt;
                &lt;text&gt;An X.509 v3 certificate structure as specified by RFC
5280, Section 4 encoded using the ASN.1 distinguished
encoding rules (DER), as specified in ITU-T X.690.
The list of certificates that run from the server
certificate towards the trust anchor.  The chain MAY
include the trust anchor certificate itself.&lt;/text&gt;
              &lt;/description&gt;
              &lt;reference&gt;
                &lt;text&gt;RFC 5280:
  Internet X.509 Public Key Infrastructure Certificate
  and Certificate Revocation List (CRL) Profile.
ITU-T X.690:
   Information technology - ASN.1 encoding rules:
   Specification of Basic Encoding Rules (BER),
   Canonical Encoding Rules (CER) and Distinguished
   Encoding Rules (DER).&lt;/text&gt;
              &lt;/reference&gt;
            &lt;/leaf-list&gt;
          &lt;/list&gt;
        &lt;/container&gt;
        &lt;action name="generate-certificate-signing-request"&gt;
          &lt;description&gt;
            &lt;text&gt;Generates a certificate signing request structure for
the associated private key using the passed subject and
attribute values.  Please review both the Security
Considerations and Design Considerations sections in
RFC VVVV for more information regarding this action
statement.&lt;/text&gt;
          &lt;/description&gt;
          &lt;input&gt;
            &lt;leaf name="subject"&gt;
              &lt;type name="binary"/&gt;
              &lt;mandatory value="true"/&gt;
              &lt;description&gt;
                &lt;text&gt;The 'subject' field from the CertificationRequestInfo
structure as specified by RFC 2986, Section 4.1 encoded
using the ASN.1 distinguished encoding rules (DER), as
specified in ITU-T X.690.&lt;/text&gt;
              &lt;/description&gt;
              &lt;reference&gt;
                &lt;text&gt;RFC 2986:
  PKCS #10: Certification Request Syntax Specification
  Version 1.7.
ITU-T X.690:
   Information technology - ASN.1 encoding rules:
   Specification of Basic Encoding Rules (BER),
   Canonical Encoding Rules (CER) and Distinguished
   Encoding Rules (DER).&lt;/text&gt;
              &lt;/reference&gt;
            &lt;/leaf&gt;
            &lt;leaf name="attributes"&gt;
              &lt;type name="binary"/&gt;
              &lt;description&gt;
                &lt;text&gt;The 'attributes' field from the CertificationRequestInfo
structure as specified by RFC 2986, Section 4.1 encoded
using the ASN.1 distinguished encoding rules (DER), as
specified in ITU-T X.690.&lt;/text&gt;
              &lt;/description&gt;
              &lt;reference&gt;
                &lt;text&gt;RFC 2986:
  PKCS #10: Certification Request Syntax Specification
  Version 1.7.
ITU-T X.690:
   Information technology - ASN.1 encoding rules:
   Specification of Basic Encoding Rules (BER),
   Canonical Encoding Rules (CER) and Distinguished
   Encoding Rules (DER).&lt;/text&gt;
              &lt;/reference&gt;
            &lt;/leaf&gt;
          &lt;/input&gt;
          &lt;output&gt;
            &lt;leaf name="certificate-signing-request"&gt;
              &lt;type name="binary"/&gt;
              &lt;mandatory value="true"/&gt;
              &lt;description&gt;
                &lt;text&gt;A CertificationRequest structure as specified by RFC
2986, Section 4.1 encoded using the ASN.1 distinguished
encoding rules (DER), as specified in ITU-T X.690.&lt;/text&gt;
              &lt;/description&gt;
              &lt;reference&gt;
                &lt;text&gt;RFC 2986:
  PKCS #10: Certification Request Syntax Specification
  Version 1.7.
ITU-T X.690:
   Information technology - ASN.1 encoding rules:
   Specification of Basic Encoding Rules (BER),
   Canonical Encoding Rules (CER) and Distinguished
   Encoding Rules (DER).&lt;/text&gt;
              &lt;/reference&gt;
            &lt;/leaf&gt;
          &lt;/output&gt;
        &lt;/action&gt;
      &lt;/list&gt;
      &lt;action name="generate-private-key"&gt;
        &lt;description&gt;
          &lt;text&gt;Requests the device to generate a private key using the
specified algorithm and key length.&lt;/text&gt;
        &lt;/description&gt;
        &lt;input&gt;
          &lt;leaf name="name"&gt;
            &lt;type name="string"/&gt;
            &lt;mandatory value="true"/&gt;
            &lt;description&gt;
              &lt;text&gt;The name this private-key should have when listed
in /keystore/private-keys.  As such, the passed
value must not match any existing 'name' value.&lt;/text&gt;
            &lt;/description&gt;
          &lt;/leaf&gt;
          &lt;leaf name="algorithm"&gt;
            &lt;type name="identityref"&gt;
              &lt;base name="key-algorithm"/&gt;
            &lt;/type&gt;
            &lt;mandatory value="true"/&gt;
            &lt;description&gt;
              &lt;text&gt;The algorithm to be used when generating the key.&lt;/text&gt;
            &lt;/description&gt;
          &lt;/leaf&gt;
          &lt;leaf name="key-length"&gt;
            &lt;type name="uint32"/&gt;
            &lt;description&gt;
              &lt;text&gt;For algorithms that need a key length specified
when generating the key.&lt;/text&gt;
            &lt;/description&gt;
          &lt;/leaf&gt;
        &lt;/input&gt;
      &lt;/action&gt;
      &lt;action name="load-private-key"&gt;
        &lt;description&gt;
          &lt;text&gt;Requests the device to load a private key&lt;/text&gt;
        &lt;/description&gt;
        &lt;input&gt;
          &lt;leaf name="name"&gt;
            &lt;type name="string"/&gt;
            &lt;mandatory value="true"/&gt;
            &lt;description&gt;
              &lt;text&gt;The name this private-key should have when listed
in /keystore/private-keys.  As such, the passed
value must not match any existing 'name' value.&lt;/text&gt;
            &lt;/description&gt;
          &lt;/leaf&gt;
          &lt;leaf name="private-key"&gt;
            &lt;type name="binary"/&gt;
            &lt;mandatory value="true"/&gt;
            &lt;description&gt;
              &lt;text&gt;An OneAsymmetricKey structure as specified by RFC
5958, Section 2 encoded using the ASN.1 distinguished
encoding rules (DER), as specified in ITU-T X.690.
Note that this is the raw private with no shrouding
to protect it.  The strength of this private key
MUST NOT be greater than the strength of the secure
connection over which it is communicated.  Devices
SHOULD fail this request if ever that happens.&lt;/text&gt;
            &lt;/description&gt;
            &lt;reference&gt;
              &lt;text&gt;RFC 5958:
   Asymmetric Key Packages
ITU-T X.690:
   Information technology - ASN.1 encoding rules:
   Specification of Basic Encoding Rules (BER),
   Canonical Encoding Rules (CER) and Distinguished
   Encoding Rules (DER).&lt;/text&gt;
            &lt;/reference&gt;
          &lt;/leaf&gt;
        &lt;/input&gt;
      &lt;/action&gt;
    &lt;/container&gt;
    &lt;list name="trusted-certificates"&gt;
      &lt;key value="name"/&gt;
      &lt;description&gt;
        &lt;text&gt;A list of trusted certificates.  These certificates
can be used by a server to authenticate clients, or by clients
to authenticate servers.  The certificates may be endpoint
specific or for certificate authorities (to authenticate many
clients at once.  Each list of certificates SHOULD be specific
to a purpose, as the list as a whole may be referenced by other
modules.  For instance, a NETCONF server model might point to
a list of certificates to use when authenticating client
certificates.&lt;/text&gt;
      &lt;/description&gt;
      &lt;leaf name="name"&gt;
        &lt;type name="string"/&gt;
        &lt;description&gt;
          &lt;text&gt;An arbitrary name for this list of trusted certificates.&lt;/text&gt;
        &lt;/description&gt;
      &lt;/leaf&gt;
      &lt;leaf name="description"&gt;
        &lt;type name="string"/&gt;
        &lt;description&gt;
          &lt;text&gt;An arbitrary description for this list of trusted
certificates.&lt;/text&gt;
        &lt;/description&gt;
      &lt;/leaf&gt;
      &lt;list name="trusted-certificate"&gt;
        &lt;key value="name"/&gt;
        &lt;description&gt;
          &lt;text&gt;A trusted certificate for a specific use.  Note, this
'certificate' is a list in order to encode any
associated intermediate certificates.&lt;/text&gt;
        &lt;/description&gt;
        &lt;leaf name="name"&gt;
          &lt;type name="string"/&gt;
          &lt;description&gt;
            &lt;text&gt;An arbitrary name for this trusted certificate. Must
be unique across all lists of trusted certificates
(not just this list) so that a leafref to it from
another module can resolve to unique values.&lt;/text&gt;
          &lt;/description&gt;
        &lt;/leaf&gt;
        &lt;leaf name="certificate"&gt;
          &lt;type name="binary"/&gt;
          &lt;description&gt;
            &lt;text&gt;An X.509 v3 certificate structure as specified by RFC
5280, Section 4 encoded using the ASN.1 distinguished
encoding rules (DER), as specified in ITU-T X.690.&lt;/text&gt;
          &lt;/description&gt;
          &lt;reference&gt;
            &lt;text&gt;RFC 5280:
  Internet X.509 Public Key Infrastructure Certificate
  and Certificate Revocation List (CRL) Profile.
ITU-T X.690:
   Information technology - ASN.1 encoding rules:
   Specification of Basic Encoding Rules (BER),
   Canonical Encoding Rules (CER) and Distinguished
   Encoding Rules (DER).&lt;/text&gt;
          &lt;/reference&gt;
        &lt;/leaf&gt;
      &lt;/list&gt;
    &lt;/list&gt;
    &lt;list name="trusted-ssh-host-keys"&gt;
      &lt;key value="name"/&gt;
      &lt;description&gt;
        &lt;text&gt;A list of trusted host-keys.  These host-keys can be used
by clients to authenticate SSH servers.  The host-keys are
endpoint specific.  Each list of host-keys SHOULD be
specific to a purpose, as the list as a whole may be
referenced by other modules.  For instance, a NETCONF
client model might point to a list of host-keys to use
when authenticating servers host-keys.&lt;/text&gt;
      &lt;/description&gt;
      &lt;leaf name="name"&gt;
        &lt;type name="string"/&gt;
        &lt;description&gt;
          &lt;text&gt;An arbitrary name for this list of trusted SSH host keys.&lt;/text&gt;
        &lt;/description&gt;
      &lt;/leaf&gt;
      &lt;leaf name="description"&gt;
        &lt;type name="string"/&gt;
        &lt;description&gt;
          &lt;text&gt;An arbitrary description for this list of trusted SSH host
keys.&lt;/text&gt;
        &lt;/description&gt;
      &lt;/leaf&gt;
      &lt;list name="trusted-host-key"&gt;
        &lt;key value="name"/&gt;
        &lt;description&gt;
          &lt;text&gt;A trusted host key.&lt;/text&gt;
        &lt;/description&gt;
        &lt;leaf name="name"&gt;
          &lt;type name="string"/&gt;
          &lt;description&gt;
            &lt;text&gt;An arbitrary name for this trusted host-key. Must be
unique across all lists of trusted host-keys (not just
this list) so that a leafref to it from another module
can resolve to unique values.

Note that, for when the SSH client is able to listen
for call-home connections as well, there is no reference
identifier (e.g., hostname, IP address, etc.) that it
can use to uniquely identify the server with.  The
call-home draft recommends SSH servers use X.509v3
certificates (RFC6187) when calling home.&lt;/text&gt;
          &lt;/description&gt;
        &lt;/leaf&gt;
        &lt;leaf name="host-key"&gt;
          &lt;type name="binary"/&gt;
          &lt;mandatory value="true"/&gt;
          &lt;description&gt;
            &lt;text&gt;An OneAsymmetricKey 'publicKey' structure as specified
by RFC 5958, Section 2 encoded using the ASN.1
distinguished encoding rules (DER), as specified
in ITU-T X.690.&lt;/text&gt;
          &lt;/description&gt;
          &lt;reference&gt;
            &lt;text&gt;RFC 5958:
   Asymmetric Key Packages
ITU-T X.690:
   Information technology - ASN.1 encoding rules:
   Specification of Basic Encoding Rules (BER),
   Canonical Encoding Rules (CER) and Distinguished
   Encoding Rules (DER).&lt;/text&gt;
          &lt;/reference&gt;
        &lt;/leaf&gt;
      &lt;/list&gt;
    &lt;/list&gt;
    &lt;container name="user-auth-credentials"&gt;
      &lt;description&gt;
        &lt;text&gt;A list of user authentication credentials that can be used
by an SSH client to log into an SSH server, using any of
the supported authentication methods (e.g., password,
public key, client certificate, etc.).&lt;/text&gt;
      &lt;/description&gt;
      &lt;list name="user-auth-credential"&gt;
        &lt;key value="username"/&gt;
        &lt;description&gt;
          &lt;text&gt;The authentication credentials for a specific user.&lt;/text&gt;
        &lt;/description&gt;
        &lt;leaf name="username"&gt;
          &lt;type name="string"/&gt;
          &lt;description&gt;
            &lt;text&gt;The username of this user.  This will be the username
used, for instance, to log into an SSH server.&lt;/text&gt;
          &lt;/description&gt;
        &lt;/leaf&gt;
        &lt;list name="auth-method"&gt;
          &lt;key value="priority"/&gt;
          &lt;description&gt;
            &lt;text&gt;A method of authenticating as this user.&lt;/text&gt;
          &lt;/description&gt;
          &lt;leaf name="priority"&gt;
            &lt;type name="uint8"/&gt;
            &lt;description&gt;
              &lt;text&gt;When multiple authentication methods in this list are
supported by the server, the one with the lowest priority
value will be the one that is used.&lt;/text&gt;
            &lt;/description&gt;
          &lt;/leaf&gt;
          &lt;choice name="auth-type"&gt;
            &lt;description&gt;
              &lt;text&gt;The authentication type.&lt;/text&gt;
            &lt;/description&gt;
            &lt;leaf-list name="certificate"&gt;
              &lt;type name="leafref"&gt;
                &lt;path value="/keystore/private-keys/private-key/certificate-chains/certificate-chain/name"/&gt;
              &lt;/type&gt;
              &lt;ordered-by value="user"/&gt;
              &lt;description&gt;
                &lt;text&gt;A list of references to certificates that can be used
for user authentication.  When multiple certificates
in this list supported by the server, the one that
comes before the others in the leaf-list will be
used.&lt;/text&gt;
              &lt;/description&gt;
            &lt;/leaf-list&gt;
            &lt;leaf-list name="public-key"&gt;
              &lt;type name="leafref"&gt;
                &lt;path value="/keystore/private-keys/private-key/name"/&gt;
              &lt;/type&gt;
              &lt;ordered-by value="user"/&gt;
              &lt;description&gt;
                &lt;text&gt;A list of references to public keys that can be used
for user authentication.  When multiple public keys
in this list supported by the server, the one that
comes before the others in the leaf-list will be
used.&lt;/text&gt;
              &lt;/description&gt;
            &lt;/leaf-list&gt;
            &lt;leaf name="ciphertext-password"&gt;
              &lt;type name="string"/&gt;
              &lt;description&gt;
                &lt;text&gt;An ciphertext password.  The method of encipherment
and how that method can be determined from this
string is implementation-specific.&lt;/text&gt;
              &lt;/description&gt;
            &lt;/leaf&gt;
            &lt;leaf name="cleartext-password"&gt;
              &lt;type name="string"/&gt;
              &lt;description&gt;
                &lt;text&gt;An cleartext password.&lt;/text&gt;
              &lt;/description&gt;
            &lt;/leaf&gt;
          &lt;/choice&gt;
        &lt;/list&gt;
      &lt;/list&gt;
    &lt;/container&gt;
  &lt;/container&gt;
  &lt;notification name="certificate-expiration"&gt;
    &lt;description&gt;
      &lt;text&gt;A notification indicating that a configured certificate is
either about to expire or has already expired.  When to send
notifications is an implementation specific decision, but
it is RECOMMENDED that a notification be sent once a month
for 3 months, then once a week for four weeks, and then once
a day thereafter.&lt;/text&gt;
    &lt;/description&gt;
    &lt;leaf name="certificate"&gt;
      &lt;type name="instance-identifier"/&gt;
      &lt;mandatory value="true"/&gt;
      &lt;description&gt;
        &lt;text&gt;Identifies which certificate is expiring or is expired.&lt;/text&gt;
      &lt;/description&gt;
    &lt;/leaf&gt;
    &lt;leaf name="expiration-date"&gt;
      &lt;type name="yang:date-and-time"/&gt;
      &lt;mandatory value="true"/&gt;
      &lt;description&gt;
        &lt;text&gt;Identifies the expiration date on the certificate.&lt;/text&gt;
      &lt;/description&gt;
    &lt;/leaf&gt;
  &lt;/notification&gt;
&lt;/module&gt;
</data>
</rpc-reply>