Ben Campbell has entered the following ballot position for draft-ietf-anima-autonomic-control-plane-16: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive Comments: - I agree with Alissa's comment about "future" things. §4: What do the normative keywords in this section apply to? If this document fulfills the requirements, it seems odd to continue to state them normatively. Normally such keywords are intended for implementors and sometimes administrators; protocol requirements don't really fit the RFC 2119/8174 definitions. If you need to use them in a non 2119/8174 sense, please mention that somewhere. §4, ACP5: SHOULD is SHOULD. If it needs to be stronger than a normal SHOULD, consider a MUST. (But see my previous comment.) §6.1.1: I'm a bit surprised to see the syntax burn 7 characters on the literal RFC name. In §6.1.1, the statement "If the operator does not own any FQDN, it should choose a string (in FQDN format) that intends to be equally unique." seems problematic without further guidance about how to actuall make them "equally unique" For example, how does one ensure this does not collide with real FQDNs? §6.1.2: Please describe how one actually checks for cert validity (e.g. explicit field comparisons) In the second bullet, how does one check for private key ownership. If the answer is "PKI", then how does that requirement differ from the following one?) §6.1.3, first paragraph: The 2nd MUST seems like a statement of fact in light of the first MUST. §6.10.1, first bullet: Does this mean the address spaces can overlap? -- last bullet: "not expected to be an end-user device" and "stay within a domain (of trust)" are both tricky assumptions. Is there a mechanism to ensure the assumptions are not violated? Editorial Comments: - IDNits reports several outdated or unused references--please check. - General: Some sections are marked as "Normative", but there are unmarked sections with normative keywords in them. Please be consistent in such labeling. (Personally, I suggest not labeling sections this way unless you think they are more likely to be misunderstood than normal.) §1.1: Please expand "RPL" on first mention. §2, definition of MIC: Why include a definition to say you don't use it in the doc? Also, please use the boilerplate from 8174 rather than rolling your own. §3 and §4: Are these sections useful to the average reader not involved in the standards process? It seems like they might be better off in an appendix or even a wg wiki, especially considering the document length. §4: This section contains a lot of sentence fragments, which I suspect were intentional. Please use complete sentences when writing in paragraph form. §6.1: Paragraphs 2 and 3 contain comma splices. §6.1.3.4: "Certificate lifetime may be set to shorter lifetimes than customary (1 year) because certificate renewal is fully automated via ACP and EST. " Are you proposing setting it to one year, or are you suggesting one year is customary? §6.1.3.4, 2nd paragraph: "allowing to simplify" is grammatically incorrect. Consider "allowing [something] to simplify" or "allowing the simplification" §6.1.3.6: The first paragraph is hard to parse. Please do not use "/" as a shortcut for a conjunction. _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
