Diego, Thanks for clearing up my misunderstanding of your Appendix A example. What you say makes sense. We will still need some way for the modeler to make his intent clear to model consumers, though, so that they can know for sure which leaves are signatures.
Happy to participate in a side meeting on this topic, and great that you will have a look at the transaction-id draft. I believe it covers quite a lot of what you’re looking for. Best Regards, /jan From: Diego R. Lopez <diego.r.lo...@telefonica.com> Date: Thursday, 18 July 2024 at 18:41 To: Jan Lindblad (jlindbla) <jlind...@cisco.com>, opsawg@ietf.org <opsawg@ietf.org> Subject: Re: draft-lopez-opsawg-yang-provenance Hi Jan, Thanks for your comments. Let me try to address them in order… Regarding the host WG, our original intent was to connect this with specific operational uses of YANG (initially, we thought only of telemetry data, but I believe other cases related with control auditability could be applicable as well) and that’s why we are proposing different mechanisms for conveying signatures (the “enclosing methods” mentioned in the draft), and not associating it with a specific way of modeling the managed elements. Hence our proposal in OPSAWG. I went to NETMOD in IETF119 more with the intention of making the group aware of our work (by indication of Rob or Joe, not sure) than to find a more appropriate home for it. This said, if the community thinks it is better to move to NETMOD, happy to explore the possibility. Regarding the use of “signature-string” element for the example of the first enclosing method in the appendix, I am afraid we did not make ourselves clear enough. The text of section 4.1 discusses the inclusion of a signature leaf in a given YANG element, and the example is built under the assumption that the “interfaces-state” model, and the corresponding XML schema, has been extended according to the procedure described in section 4.1. This is not said in Appendix A and hence the interpretation you make. We will correct the text to make this point clear. So far, we are considering four enclosing methods: 1. Updating the model to include a leaf signature element 2. Including signatures in YANG-Push notifications 3. Including signatures as metadata in data instances 4. Including signatures in annotations We could consider a fifth one associated with transaction IDs. I’ll have a look at the draft. Finally, let me say I will be more than happy to discuss these (and any other) details with you. Please, @OPSAWG, consider this a call for anyone else interested in this matter, so we can try to organize a side meeting. If not, let’s look for an appropriate time for discussing this one-to-one. Be goode, -- “Esta vez no fallaremos, Doctor Infierno” Dr Diego R. Lopez Telefonica I+D https://www.linkedin.com/in/dr2lopez/ e-mail: diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com> Mobile: +34 682 051 091 --------------------------------- On 17/7/24, 14:20, <jlind...@cisco.com> wrote: AVISO/WARNING: Este correo electrónico se originó desde fuera de la organización. No haga clic en enlaces ni abra archivos adjuntos a menos que reconozca al remitente y sepa que el contenido es seguro / This email has been originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Diego, I think this is interesting work, and I’d like to see this evolve. I would somewhat prefer that this work lives in NETMOD. I suspect more people would be interested there, but I guess either WG could work. When it comes to the detailed expression of the signature in XML payload, I don’t think the current approach works. In Appendix A one of the examples contains the following: <interfaces-state xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> <signature-string> 0oRRowNjeG1sBGdlYzIua2V5ASag9lhAvzyFP5HP0nONaqTRxKmSqerrDS6CQXJSK+5NdprzQZLf0QsHtAi2pxzbuDJDy9kZoy1JTvNaJmMxGTLdm4ktug== </signature-string> <interface> <name>GigabitEthernet1</name> According to XML encoding/decoding rules, the above means the signature-string tag is defined in the ietf-interfaces module, which it clearly is not. So a violation of basic XML principles. We also need to find a way for clients to reliably identify these signature strings. Perhaps this could be solved in a similar way as with the NETCONF+RESTCONF transaction-id values, as described in https://datatracker.ietf.org/doc/draft-ietf-netconf-transaction-id/ In fact, one of the use cases for transaction-id is precisely to provide cryptographic signatures for the payload. In any case, I’d be happy to participate in a discussion (privately, or as a side meeting, or whatever) around how these signature tags would ideally be handled in XML and other transport encodings. Best Regards, /jan From: opsawg-requ...@ietf.org <opsawg-requ...@ietf.org> Date: Monday, 15 July 2024 at 20:21 To: opsawg@ietf.org <opsawg@ietf.org> Subject: OPSAWG Digest, Vol 206, Issue 54 Send OPSAWG mailing list submissions to opsawg@ietf.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to opsawg-requ...@ietf.org You can reach the person managing the list at opsawg-ow...@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OPSAWG digest..." Today's Topics: 1. Re: draft-lopez-opsawg-yang-provenance (Diego R. Lopez) 2. Re: draft-lopez-opsawg-yang-provenance (Joe Clarke (jclarke)) ---------------------------------------------------------------------- Message: 1 Date: Mon, 15 Jul 2024 17:44:31 +0000 From: "Diego R. Lopez" <diego.r.lo...@telefonica.com> Subject: [OPSAWG]Re: draft-lopez-opsawg-yang-provenance To: Mahesh Jethanandani <mjethanand...@gmail.com>, "Joe Clarke (jclarke)" <jclarke=40cisco....@dmarc.ietf.org> Cc: "opsawg@ietf.org" <opsawg@ietf.org> Message-ID: <ve1pr06mb71504f817e2c743a7a8f81b1df...@ve1pr06mb7150.eur prd06.prod.outlook.com> Content-Type: multipart/alternative; boundary="_000_VE1PR06MB71504F 817E2C743A7A8F81B1DFA12VE1PR06MB7150eurp_" Hmmm… My understanding was that it was supposed to continue in OPSAWG and not move to NETMOD, as it started its way in OPSWAG in 116, if I remember well. Be goode, -- “Esta vez no fallaremos, Doctor Infierno” Dr Diego R. Lopez Telefonica I+D https://www.linkedin.com/in/dr2lopez/ e-mail: diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com> Mobile: +34 682 051 091 --------------------------------- On 15/7/24, 18:12, <mjethanand...@gmail.com> wrote: Hi Michael/Joe, I looked at the minutes of NETMOD from 119, and Kent’s comment was that: It sounds like you are still experimenting on this. I suggest to bring it back and give an update when you are ready and we can guage interest. There was no suggestion that it should be taken to OPSAWG. Thanks. On Jul 15, 2024, at 9:08 AM, Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org<mailto:jclarke=40cisco....@dmarc.ietf.org>> wrote: Thanks for the read-through, Michael. This work was presented in opsawg and netmod before. At 119, it was presented in netmod, and Diego got the comment from Kent that this seemed experimental and to come back when more work has been done. Diego wants to discuss the implementation work they’ve done, and I feel this is a valid comment for his adoption question: should this be in opsawg or netmod? Joe From: Michael Richardson <mcr+i...@sandelman.ca<mailto:mcr+i...@sandelman.ca>> Date: Monday, July 15, 2024 at 11:51 To: opsawg@ietf.org<mailto:opsawg@ietf.org> <opsawg@ietf.org<mailto:opsawg@ietf.org>> Subject: [OPSAWG]draft-lopez-opsawg-yang-provenance Hi Joe, reading the agenda, I was interested in: https://datatracker.ietf.org/doc/draft-lopez-opsawg-yang-provenance/ why isn't this in NETMOD? -- Michael Richardson <mcr+i...@sandelman.ca<mailto:mcr+i...@sandelman.ca>> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org<mailto:opsawg@ietf.org> To unsubscribe send an email to opsawg-le...@ietf.org<mailto:opsawg-le...@ietf.org> Mahesh Jethanandani mjethanand...@gmail.com<mailto:mjethanand...@gmail.com> ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição -------------- next part -------------- A message part incompatible with plain text digests has been removed ... Name: not available Type: text/html Size: 13672 bytes Desc: not available ------------------------------ Message: 2 Date: Mon, 15 Jul 2024 18:20:10 +0000 From: "Joe Clarke (jclarke)" <jcla...@cisco.com> Subject: [OPSAWG]Re: draft-lopez-opsawg-yang-provenance To: Mahesh Jethanandani <mjethanand...@gmail.com> Cc: "opsawg@ietf.org" <opsawg@ietf.org> Message-ID: <bn9pr11mb53718a603063b4466354d17db8...@bn9pr11mb5371.nam prd11.prod.outlook.com> Content-Type: multipart/alternative; boundary="_000_BN9PR11MB53718A 603063B4466354D17DB8A12BN9PR11MB5371namp_" Right, there was no suggestion there. I didn’t mean to imply it was. I was saying that Kent’s comment implied the draft might come back to netmod after more progress. …But it had already been presented at opsawg at previous meetings. This isn’t net-new work to opsawg. If the WG doesn’t see interest in adopting, then perhaps this would fit better in netmod. As a chair here, I appreciate the feedback as this helps us gauge working group interest. Joe From: Mahesh Jethanandani <mjethanand...@gmail.com> Date: Monday, July 15, 2024 at 12:12 To: Joe Clarke (jclarke) <jcla...@cisco.com> Cc: Michael Richardson <mcr+i...@sandelman.ca>, opsawg@ietf.org <opsawg@ietf.org> Subject: Re: [OPSAWG]Re: draft-lopez-opsawg-yang-provenance Hi Michael/Joe, I looked at the minutes of NETMOD from 119, and Kent’s comment was that: It sounds like you are still experimenting on this. I suggest to bring it back and give an update when you are ready and we can guage interest. There was no suggestion that it should be taken to OPSAWG. Thanks. On Jul 15, 2024, at 9:08 AM, Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org<mailto:jclarke=40cisco....@dmarc.ietf.org>> wrote: Thanks for the read-through, Michael. This work was presented in opsawg and netmod before. At 119, it was presented in netmod, and Diego got the comment from Kent that this seemed experimental and to come back when more work has been done. Diego wants to discuss the implementation work they’ve done, and I feel this is a valid comment for his adoption question: should this be in opsawg or netmod? Joe From: Michael Richardson <mcr+i...@sandelman.ca<mailto:mcr+i...@sandelman.ca>> Date: Monday, July 15, 2024 at 11:51 To: opsawg@ietf.org<mailto:opsawg@ietf.org> <opsawg@ietf.org<mailto:opsawg@ietf.org>> Subject: [OPSAWG]draft-lopez-opsawg-yang-provenance Hi Joe, reading the agenda, I was interested in: https://datatracker.ietf.org/doc/draft-lopez-opsawg-yang-provenance/ why isn't this in NETMOD? -- Michael Richardson <mcr+i...@sandelman.ca<mailto:mcr+i...@sandelman.ca>> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org<mailto:opsawg@ietf.org> To unsubscribe send an email to opsawg-le...@ietf.org<mailto:opsawg-le...@ietf.org> Mahesh Jethanandani mjethanand...@gmail.com<mailto:mjethanand...@gmail.com> -------------- next part -------------- A message part incompatible with plain text digests has been removed ... Name: not available Type: text/html Size: 9586 bytes Desc: not available ------------------------------ Subject: Digest Footer _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org ------------------------------ End of OPSAWG Digest, Vol 206, Issue 54 *************************************** ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
