I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Autonomic network management, whose name means "involuntary or unconscious", is an experimental technology in which networks are given degrees of freedom we have not given them before to determine their operating parameters. I am in favor of it; if it is unnecessary to pre-determine the prefix that a new portion of a network might use, I'm not sure why we have to make that choice difficult. At the same time, I am hesitant to say "be ye not afraid"; Mike O'Dell famously quipped that "if you are not afraid [in operational matters], you don't understand". I am very sure that as we deploy networks using this technology, which we have never tried before, we will be required to answer questions we didn't think to ask, and the resulting paradigms and protocols will change accordingly. For that reason, I would prefer that all of the anima drafts and RFCs were labelled "experimental", and their successors considered "informational" or "standard". This is not a statement of aversion to autonomic technologies; it is an encouragement to conservative exploration of a new intellectual frontier. I would encourage us to be liberal in the new paradigms we accept, and conservative in experimental design. As draft-ietf-anima-prefix-management notes, it is not a complete functional specification, and doesn't address all possible use cases. In practical deployment, I can imagine it facilitating operational deployments, making it easier for an ISP or Enterprise network to deploy services quickly. I can imagine the operator in question then recording the configuration autonomically derived, and either fossilizing it in network configuration or overriding it in view of future intentions and plans. Or both... I think the draft identifies the issues that a deployment might reasonably be faced with, and identifies reasonable solutions. It does mean deployment of GRASP, which to my knowledge has not been deployed in anger before on a network-wide basis, and network design that facilitates GRASP making good decisions. Hence, I would suggest that an operator new to the technology to be very aware of what it results in, and be prepared to change those configurations if they are unsatisfactory. "Don't make assumptions that are unwarranted in your experience." I would encourage the authors to write, at an appropriate time in the future, an "experience" draft such as we used to write for routing protocols (RFC 1246 comes to mind). It should report on operational deployments, what the experience was, what issues were found, and what changes were made as a result. My assessment: proceed, but with advisable caution.