On 17-Dec-19 09:08, Alissa Cooper wrote: > Thanks Michael. Should Section 8.1 now be removed as well?
I think that's a good catch. FYI and largely irrelevant, I did lash together some code at the IETF106 hackathon using GRASP to communicate a MUD URL to the network management system. So if we need to integrate MUD handling into the ANIMA infrastructure, there's already a proof of concept, without complicating BRSKI. Brian > > Alissa > >> On Dec 16, 2019, at 2:56 PM, Michael Richardson <[email protected]> >> wrote: >> >> >> {Hi Tom, I don't quite understand, but I don't seem to get emails directly >> From you. Or perhaps it has to do with it being posted through the >> datatracker. This is not the first review I have missed in this way.} >> >> We had forgotten about the content of Appendix C, which is not normative. >> It stems from an era when we were not sure how successful RFC8520 will be. >> >> I have issued version -31 in which we remove Appendix C rather than fix it. >> >> This extension could be added correctly at a later date, and at this point, >> we don't see the MUD FILE->MASA URL flow as particularly important. >> >> Both URLs can be in the IDevID if needed, at the cost of bytes in the IDevID >> certificate. >> >> I think that there are operational problems with embedding the MUD URL in the >> IDevID relating to firmware upgrades, nor is that related to this appendix. >> It is not a BRSKI issue, but it does mean that the likelyhood of a MUD URL >> being the only extension that can be afforded an IDevID is significantly less >> likely. >> >> -- >> Michael Richardson <[email protected]>, Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
