Query on whether following format is supported in netopeer2 parsing.

[Abrahamma97]

Hi @michalvasko, I am able to configure and give algorithm <algorithm>rsa2048</algorithm> but do we have support to configure leaves in this format as below <algorithm xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">ct:rsa2048</algorithm>in Netopeer2. If so from which version as I did not see in 1.1.70.

Please refer page 6 of https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-13 for the exact permission

     <client-identity>
       <username>foobar</username>
       <public-key>
         <local-definition>
           <algorithm xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">ct:rsa2048</algorithm>
           <private-key>base64encodedvalue==</private-key>
           <public-key>base64encodedvalue==</public-key>
         </local-definition>
       </public-key>
     </client-identity>

[michalvasko]

No, this is not supported in the drafts we have implemented. But I am puzzled because these algorithms are defined as identities in the ietf-crypto-types module published in a draft on 02-07-2019, which should be the one we are using. But it is an enumeration in our local copy but I am pretty sure I have extracted the YANG modules directly from the drafts so like I said, I have no idea where this difference originates from.

In any case, we will not be spending time on any updates of these modules. We are waiting until all these modules are finally published as RFCs and only then will implement the final modules.

[Abrahamma97]

Hi @michalvasko, Can you please update on this thread after implementing even if it takes time? Thanks for your time.

[michalvasko]

Not sure when that is going to happen but I will try not to forget. Like I said, the first condition before we can even make some plan as when to implement this is the publication of RFCs from the current drafts.

[pengpengpeng666]

Hi @michalvasko , For ietf-crypto-types.yang with revision 2019-04-29 , these algorithms are defined as identities. is there anyway to support the old revision? Or could it both support 2019-04-29 and 2019-07-02?

[pengpengpeng666]

Hi @michalvasko After checking history, this change was made in commit 5333569, where the 2019-04-29 yang files are changed to 2019-07-02.

Some organizations, like ORAN, are still using 2019-04-29 yang files. Is there any way for backwards compatible?

Many Thanks!

[michalvasko]

Sorry, but keeping backwards compatibility for draft YANG modules is simply not worth it. It is unfortunate these modules are taking such a long time to be properly published.