On behalf of D. Lopez:
At a first glance, I miss some element(s) related to ensure provenance (signatures or something similar). I know it could be argued that this could be somehow derived from the transport, but I believe some degree of self-assertion is important for further reuse in a number of scenarios.
B. Claise:
Exactly "some degree of self-assertion is important for further reuse in a number of scenarios.
Now regarding the provenance, it could come from the router itself, from the SAIN agent, or from the SDA.... basically from whoever knows exactly how the data was metered. This information would be forwarded as management plane information.
In theory this data could modified by a bad guy... However, if a bad guy has access to your management data in your NOC & big data lake, I'm not sure it's his highest priority.
We could always discuss though; maybe I overlooked something.
D. Lopez:
My point was not about the source of the provenance proofs, but about including them in the manifest for further verification, whether you want to verify the manifest itself, or (making these data richer) use these proofs as root of trust for verifying that data associated to the manifest.
Feedback from Eliot Lear during IETF 112
@Benoit, for the platform manifest have you considered using YANG packages to describe the supported software in a hierarchical way?
On behalf of D. Lopez:
At a first glance, I miss some element(s) related to ensure provenance (signatures or something similar). I know it could be argued that this could be somehow derived from the transport, but I believe some degree of self-assertion is important for further reuse in a number of scenarios.
B. Claise:
Exactly "some degree of self-assertion is important for further reuse in a number of scenarios. Now regarding the provenance, it could come from the router itself, from the SAIN agent, or from the SDA.... basically from whoever knows exactly how the data was metered. This information would be forwarded as management plane information. In theory this data could modified by a bad guy... However, if a bad guy has access to your management data in your NOC & big data lake, I'm not sure it's his highest priority. We could always discuss though; maybe I overlooked something.
D. Lopez:
My point was not about the source of the provenance proofs, but about including them in the manifest for further verification, whether you want to verify the manifest itself, or (making these data richer) use these proofs as root of trust for verifying that data associated to the manifest.