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 <kent+i...@watsen.net> wrote:
> Hi Jensen,
>
> On Dec 12, 2023, at 7:47 AM, Jensen Zhang <jingxuan.n.zh...@gmail.com>
> 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
>
>
_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
