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. First, I'm sorry this review is a few days late, and I hope that isn't a problem. Second, the document is "ready with issues". Most of the comments below are minor, and editorial. The three that are substantive are: 1. SHOULD vs MUST with respect to encryption in Sections 3.5.1 and 3.5.2.1. 2. The UTF-8 issues in Section 3.10.1. 3. Guidance for the Designated Expert in Section 7. These should all be easy to resolve. — Section 1 — A reference model for autonomic networking on this basis is given in [I-D.ietf-anima-reference-model]. The reader should consult this document to understand how various autonomic components fit together. Even though that document is an informative reference, I find it odd that the draft that helps us understand how this all fits together. . . is an expired draft. It makes me wonder how well baked things are. — Section 3.1 — The following additional terms are used throughout this document: o Autonomic Device: identical to Autonomic Node. It’s not a big point, but: Why? Why is it important or useful to specifically define a *new* term in this document that has the same meaning as a similar term that’s already defined? And, actually, now that I check, I see that “autonomic devices” is used in exactly one place, in the Abstract. I suggest changing the term in the abstract to “autonomic nodes”, and removing this definition. — Section 3.2 — Because GRASP needs to work whatever happens, especially during bootstrapping and during fault conditions, it is essential that every implementation is as robust as possible. There seems to be a missing word, or some such; I can’t parse “GRASP needs to work whatever happens”. And picky grammatical nit: subjunctive mood is needed with “essential”, so it should be “it is essential that every implementation be as robust as possible.” — Section 3.3 — GRASP provides mechanisms to guarantee convergence (or failure) in a small number of steps, i.e. a timeout and a maximum number of iterations. Another nit. This is an outstanding example of why I don’t like to use “i.e.”: in this case, it leaves me wondering whether that’s really an exhaustive list, or whether you meant “e.g.”. And, to me, it reads awkwardly anyway. I suggest one of these alternatives (the sorts that can pretty much always stand in for the overused and unnecessary “i.e.”): NEW-1 GRASP provides two mechanisms to guarantee convergence (or failure) in a small number of steps: a timeout and a maximum number of iterations. NEW-2 GRASP provides a timeout and a maximum number of iterations, which together guarantee convergence (or failure) in a small number of steps. — Section 3.5.1 — If there is no ACP, the protocol MUST use another form of strong authentication and SHOULD use a form of strong encryption. See Section 3.5.2.1 for further discussion. Both here and in 3.5.2.1: Why is encryption SHOULD, and not MUST? Looking ahead to 3.5.2.1, how could it be considered safe to use a network configuration protocol across administrative boundaries without encryption? — Section 3.5.2.2 — A responder SHOULD NOT send a Discovery Response message unless it cannot be avoided. Any clue about why it might be possible that it “cannot be avoided”? — Section 3.5.2.3 — o Any type of GRASP message MAY be sent. This doesn’t feel like a “MAY” to me. You’re not saying that there’s a protocol choice here, and how to handle it is optional and up to the implementation. You’re saying that all types of GRASP messages are permitted when you’re using a SONN instance. So maybe, “All types of GRASP messages are permitted.” — Section 3.10.1 — All objectives are identified by a unique name which is a case- sensitive UTF-8 string. Actually, “case-sensitive” isn’t a sufficient descriptor for UTF-8, as there are issues of canonicalization and normalization, and the fact that languages differ in whether “case” makes sense at all. This would be a bigger issue if you wanted case insensitivity, but as it is I think the fix is easy: you should just say that the name is a UTF-8 string that is compared byte by byte. This will have the effect of being case sensitive when that makes sense, and will also eliminate the issues of canonicalization and normalization: different ways of representing characters such as “ä” and “ô” and “é” will compare as different, and as these are protocol elements and not user strings, that should be fine. The other question is whether there are any restrictions on what Unicode characters can be represented. You make the colon a special character but give no other restrictions, so an objective name could include space characters (and various related Unicode characters such as tab, EN SPACE, ZERO WIDTH SPACE, and ZERO WIDTH NON-JOINER), control characters (FORM FEED, CARRIAGE RETURN, and the like), characters from every character set and language including Cuneiform and Egyptian Hieroglyphs, and even such iconic characters as MUSICAL SYMBOL G CLEF, ONCOMING POLICE CAR, and the famous PILE OF POO. If that’s all OK, then that’s fine (and maybe it is, as, again, this is a protocol element, not a user string). I just want to make sure you thought about it. — Section 7 — The creation of the Specification Required registry for the Objective Names Table needs to specify guidance for the Designated Expert (see draft-leiba-cotton-iana-5226bis, Sections 4.6 and 4.5). It doesn’t have to be a lot, but it needs to be clear for future DEs who might not have been involved with developing this document what they need to consider as they review registration requests. Why might they push back on a registration request? Should they, for example, allow registration requests for two different Objective Names of “frobozz” and “Frobozz”? What sort of documentation is sufficient for a registration (is “enough that you think implementations can be written from it” good enough, or are there specific things that the documentation ought to contain)? -- Barry