I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

I think the document is now "ready with nits". 

In my previous review of draft-ietf-anima-bootstrapping-keyinfra-16, I raised a number of concerns. The new version draft-ietf-anima-bootstrapping-keyinfra-20 addresses these concerns in two main ways: an applicability statement that restricts usage of the protocol to the "Autonomous Networking" scenario, and an improved security section. My main request is that the applicability discussion does not present the trade-off between between ease of bootstrap and increased manufacturer control. This should be easy to fix.

The new version introduces applicability restriction in the Introduction, stating that the draft "provides for the needs of the ISP and Enterprise focused ANIMA Autonomic Control Plane (ACP)" and that other scenarios will require separate applicability statements. This is developed in section 8, "Applicability to the Autonomic Control Plane". This is a welcome change. It addresses some of the concerns raised in the previous review, such as use of BRSKI in consumer IOT scenarios.

The previous review also raised a series of concerns related to the balance of power between manufacturer and owner of the device. These concerns are discussed in section 9, Privacy Considerations. The text in sections 9.2 points out that leakage of information is limited to the one-time bootstrap of the device. Section 9.3 addresses concerns expressed during the review about resale of devices, and points out that any mechanism intended to prevent theft will also prevent resale. That's true, but the mechanism designed to enable legitimate sales is only vaguely sketched: "the initial owner could inform the manufacturer of the sale, or the manufacturer may just permit resales unless told otherwise." Could and may, but there is no protocol element describing either option. Similarly, the section addresses manufacturer decisions to "end of life" a device by essentially stating that such devices will only be usable if they are never reset to factory default. Section 9.4 goes on explaining how the protocol can be used to thwart grey-market sales and resales, and simply state that it is legitimate for manufacturers to do that.

As a whole, these three subsections of section 9 read very much like a justification of the original design. They could be summarized by stating that involving the manufacturer in the one-time bootstrapping provides new device owners with an automated and secure way to bootstrap devices, at the cost of increased manufacturer control on the devices' lifetime and resale. That trade-off may not be acceptable by every potental owner. Section 9.5 describes an interesting mitigation. It explains that manufacturer controls could be bypassed by replacing the certificate built in the device, and pointing it to a new MASA. That's obviously true, but I don't believe that the mechanisms for doing that are stated in the draft. In the absence of that mechanism, I would suggest to present the tradeoff between ease of bootstrap and increased manufacturer control in the introduction, perhaps in the same paragraph that states the domain of applicability of the draft.

The security section covers several of the issues pointed out in the previous review. Section 10.1 explains how MASA availability issues (e.g. DoS attacks) are mitigated (10.1) by availability of nonceless vouchers. Section 10.2 explains how attacks by fake registrars could be detected by examining audit logs from the MASA. Section 10.3 discusses attacks by misbehaving MASA, and effectively conclude that they are not worse than if the device was bootstrapped without MASA. Continuous availability of MASA private key is discussed in 10.4.

My previous review asked whether devices were expected to issue random numbers, and whether they should be equipped with appropriate random number generators. The protocol itself does not rely on random numbers generated by the device -- it only requires that the device be capable of generating a nonce. On the other hand, the protocol relies on HTTPS and thus TLS, which itself does require devices capable of generating cryptographically secure random numbers. The concern there is that BRSKI is engaged after the device is "reset to factory condition". This is probably easily mitigated, but might require a mention somewhere.

A small nit about section 2.3 example:Text of first example says "The assertion leaf is indicated as 'proximity'", but there is no "assertion" leaf in the example voucher. Is this leftover from previous draft version?

I also noticed a number of typos, especially in the added text. Running a spell check would help.