* Why x86 only when there is a SPARC newboot case in progress now, this alone is a possible reason to derail. for me.
* SPARC already has wanboot that has a lot of similarities in the problem space - and is actually a secure solution. * Why bootparams rather than DHCP - mixing them is ugly especially on x86 which almost never uses bootparams these days. WAN Boot uses DHCP and it did have to add new options - some might be reusable by this case. * Mention of "rc" script - this must be an SMF service * CHAP authentication is not secure enough, you really need IPsec. However getting IPsec (even manually keyed) running early in boot will be challenging - partly because of the userland need and partly because of crypto not being available until kcfd is up (which is currently after /usr) If we have reason we can fix that though. * Why can't at least CHAP be done in the first phase ? Security isn't optional and many of the use cases for iSCSI boot would be similar to wanboot - so assuming physical security is not acceptable. Personally I don't feel as if this case is anywhere near complete architecturally since it seems clear to me that it hasn't considered existing things like WANboot. This case just doesn't see obvious to me and I would have expected some thing as significant as this to be fully coordinated with SPARC newboot and be a full case. -- Darren J Moffat
