Well, I take that back. I think all these points can be slipped into this week's update of the draft (I plan to submit that on Friday NZ time).
Two points for the WG: > > — 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? Input please, or else you will see this as an open issue in Chicago. Personal opinion: encryption should be a MUST. On UTF-8: > 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), Once we specify byte-by-byte comparison, do we need to worry about this in a protocol document? If someone is silly enough to specify an objective called 'example.org:Недостаточно握 déjà vu ' do we care, in the protocol design? Personal opinion: we don't need to say anything. Regards Brian On 08/03/2017 16:44, Brian E Carpenter wrote: > 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
