Thanks Barry. Good comments, but we have to get a new draft out before the deadline, so I'm not sure these will all make it in until the one after.
Regards Brian On 08/03/2017 15:43, Barry Leiba wrote: > 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)? > _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
