Subject: [Anima] Ben Campbell's No Objection on draft-ietf-anima-autonomic-control-plane-16: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 01 Aug 2018 15:17:09 -0700

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.