Hi all,
Kent, fwiw the alto draft was already in the IESG review and that a new version
is expected to come address the IETG review.
On the specific point about moving some items to
draft-ietf-netconf-trust-anchor, this will introduce a direct normative
dependency to draft-ietf-netconf-trust-anchor, which was indirect via
draft-ietf-netconf-tls-client-server.
Having direct or indirect dependency won’t change the fact that the ALTO spec
will be waiting in seems to be a large cluster for
draft-ietf-netconf-trust-anchor, but this will require some effort to track
whether changes to the groupings in draft-ietf-netconf-trust-anchor do not have
implication on the ALTO spec.
Cheers,
Med (ALTO OAM doc Shepherd)
De : netconf <netconf-boun...@ietf.org> De la part de Jensen Zhang
Envoyé : mercredi 13 décembre 2023 03:33
À : Kent Watsen <kent+i...@watsen.net>
Cc : draft-ietf-netconf-trust-anch...@ietf.org; netc...@ietf.org; IETF ALTO
<alto@ietf.org>
Objet : Re: [netconf] Comment on typedef 'public-key-ref' of
draft-ietf-netconf-trust-anchors-21
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<mailto:kent%2bi...@watsen.net>> wrote:
Hi Jensen,
On Dec 12, 2023, at 7:47 AM, Jensen Zhang
<jingxuan.n.zh...@gmail.com<mailto: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
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
