Re: [netconf] Comment on typedef 'public-key-ref' of draft-ietf-netconf-trust-anchors-21

[Jensen Zhang <[e-mail]>]

Hi Kent,

Thanks for your quick response.

Maybe I did not make it clear. I am just pointing out a very simple
specific issue in the current 'ietf-truststore' module, which is that the
typedef 'public-key-ref' cannot be used by another module.

The reason is very simple: Based on the description, if module A wants to
use this typedef to reference a public key in the central trust store, it
is supposed to provide another sibling leaf node called 'public-key-bag'
that has the typedef 'public-key-bag-ref', so that the public-key-ref can
use the relative path '[ts:name = current()/../ts:public-key-bag]' to
locate in which public-key-bag the referenced public key should be.
However, in this relative path, 'public-key-bag' is prefixed by 'ts', it
cannot reference the sibling leaf node 'public-key-bag' defined in module A
correctly.

The fix should also be very simple: Just remove the prefix of the
'public-key-bag', i.e.,

OLD:

         + "[ts:name = current()/../ts:public-key-bag]/"

NEW:

         + "[ts:name = current()/../public-key-bag]/"

You mentioned that the 'ietf-restconf-server' module also uses the
'ietf-truststore' module. But does it use the typedef 'public-key-ref'
anywhere? I don't find any other module that uses the current typedef
'public-key-ref'. Do you have such a successful example?

About your other feedback, please see my responses inline :)

Thanks,
Jensen

On Wed, Dec 13, 2023 at 2:36 AM Kent Watsen <[e-mail]> wrote:

> Hi Jensen,
>
> On Dec 12, 2023, at 7:47 AM, Jensen Zhang <[e-mail]>
> wrote:
>
> Hi authors,
>
> I am one of the authors of the draft-ietf-alto-oam-yang draft. Our draft
> is trying to reuse some groupings and typedefs in this document to support
> some TLS authentication features. But we find the current typedef
> 'public-key-ref' cannot be used by another module.
>
> To be more concrete, in the current document, the path of the typedef
> 'public-key-ref' enforces a prefix of the relative path to the sibling
> 'public-key-bag' leaf:
>
>    typedef public-key-ref {
>      type leafref {
>        path "/ts:truststore/ts:public-key-bags/ts:public-key-bag"
>          + "[ts:name = current()/../ts:public-key-bag]/"
>          + "ts:public-key/ts:name";
>      }
>      ...
>    }
>
> From my understanding, this typedef is for other modules to reference a
> public key in the trust store. The sibling 'public-key-bag' leaf should be
> in the same module of the leaf using this typedef, instead of the module
> 'ts'.
>
> To make this typedef usable, I believe it should look like the following:
>
>    typedef public-key-ref {
>      type leafref {
>        path "/ts:truststore/ts:public-key-bags/ts:public-key-bag"
>          + "[ts:name = current()/../public-key-bag]/"
>          + "ts:public-key/ts:name";
>      }
>      ...
>    }
>
> Otherwise, we have to define another typedef in our own module like this:
> https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/blob/284d2e630cec00f752ea94f586469797786c6f57/yang/ietf-alto.yang#L612-L628
>
>
> This is my first time looking at Alto.  It may take me a little to fully
> grok what’s going on.  Please let me know if you think a call would be
> helpful.
>
> Looking at the linked YANG module, I see that it looks very much like the
> "ietf-restconf-server" module’s grouping
> "restconf-server-listen-stack-grouping”, which is fine.
>
> I take it that Alto is okay referencing the central truststore (not
> defining its own instances of "truststore-grouping") as well as supporting
> inlined definitions.  I do not see the Alto module augmenting the
> centralized truststore and, in general, it seems to behave just like the ietf-restconf-server
> module, though I’m sure I’m missing something  ;)
>
> What I don’t understand is why what seems to work in ietf-restconf-server
> doesn’t work in ietf-alto.  Can you help me understand?
>
> Separately, did ALTO WG ever consider renaming to “ietf-alto-server”?
> Would there be value to extending that convention for consistency?
>

The module 'ietf-alto' provides both server and client configurations. I
guess you are suggesting to separate them into two modules. It may not be
necessary unless somebody has a strong opinion on this. But still thanks
for your comment.


>
> One last thought, I notice that ietf-alto defines a number of typedefs
> that seem generic enough to move to ietf-truststore.  Is this thought yours
> as well?
>

Good point. The reason why ietf-alto defines those typedefs and groupings
is that we don't find the reusable typedefs and groupings in another
module. It definitely will be great if ietf-truststore can provide some of
them.

Specifically, I believe the typedef 'public-key-ref' and grouping
'truststore-public-key-ref' can be moved to ietf-truststore.

But for the typedefs and groupings related to the inline certificates, I
have no idea how to make them generic properly. Because the inline
certificates defined by the 'inline-or-truststore-certs-grouping' grouping
will have different absolute paths when it is used in different modules.


>
>
> Thanks,
> Jensen
>
>
>
> Kent   // author
>
>