Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)

[tom petch <[e-mail]>]

Michael,  my initial posts were a response to the Genart review and so 
did not include your name, just Anima, Anima chairs, ibagdona, IETF; you 
are in this one as [e-mail] (but IETF mailers may have a 
habit of thinking you will get an e-mail via one way and suppress other 
ways with different e-mail addresses).

Yes you have removed the second YANG module which addresses my comments 
about the second YANG module but my other comments mostly remain.  Those 
about the YANG prefix are fixed.


RFC8040  needs to be in the I-D References

IANA Considerations mentions the removed module but lacks the two 
required actions for the remaining module

XXXX is used as a place holder for a document name which is not that of 
this I-D and does not exist AFAICT

The YANG module must be plain text - [RFC8446] looks like HTML/XML

Security Considerations lacks the required boiler plate for a YANG module

Appendix A still has a typo

Tom Petch

On 16/12/2019 19:56, Michael Richardson 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 <[e-mail]>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
>
>
>