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

[Kent Watsen <[e-mail]>]

Hi Jensen,

> On Dec 12, 2023, at 9:32 PM, Jensen Zhang <[e-mail]> wrote:
> 
> 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?

Oh, now I get it.  Okay, change made in my local copy.   I also made the same fix for `typedef certificate-ref`.


> About your other feedback, please see my responses inline :)
> 
> Thanks,
> Jensen
> 
> On Wed, Dec 13, 2023 at 2:36 AM Kent Watsen <[e-mail] <mailto:[e-mail]>> wrote:
>> Hi Jensen,
>> 
>>> On Dec 12, 2023, at 7:47 AM, Jensen Zhang <[e-mail] <mailto:[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.


"typedef public-key-ref” (and "typedef certificate-ref”) already exists.  Nothing to do here (other than the fix mentioned above).

"grouping truststore-public-key-ref” and "grouping truststore-certificate-ref” have been added 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.

Nowhere in any of the client-server drafts do we enable configuration to reference an inlined thing.  That would defeat the purpose of inlining things.  If you find the need for referencing inlined things, it suggests the need to NOT inline some things.


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