Robert Wilton has entered the following ballot position for draft-ietf-anima-autonomic-control-plane-28: 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: ---------------------------------------------------------------------- Hi, I appreciate that this document has already gone through quite a lot of reviews. Just a few minor nits (for the version of the doc that was originally on the telechat before IETF 108): 6.1. ACP Domain, Certificate and Network This document uses the term ACP in many places where the Autonomic Networking reference documents [RFC7575] and [I-D.ietf-anima-reference-model] use the word autonomic. This is done because those reference documents consider (only) fully autonomic networks and nodes, but support of ACP does not require support for other components of autonomic networks except for relying on GRASP and providing security and transport for GRASP. Therefore the word autonomic might be misleading to operators interested in only the ACP. Should this paragraph be somewhere earlier in the document? 6.1.2. ACP Certificate AcpNodeName The acp-node-name is not intended for end user consumption, and there is no protection against someone not owning a domain name to simpy choose it. The latter part of this sentence doesn't seem to scan particularly well. 6.7.3.1.1. RFC8221 (IPsec/ESP) AH MUST NOT be used (because it does not provide confidentiality). Do you need AH in the terminology or define what it means? 6.7.4. ACP via DTLS We define the use of ACP via DTLS in the assumption that it is likely the first transport encryption supported in some classes of constrained devices because DTLS is already used in those devices but IPsec is not, and code-space may be limited. DTLS in the assumption => DTLS, on the assumption This paragraph could possibly do with a little more wordsmithing. 6.10.1. Fundamental Concepts of Autonomic Addressing For a PE device or NID, how does it know which interfaces to run ACP over? o OAM protocols do not require IPv4: The ACP may carry OAM protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, Radius, Diameter, ...) are available in IPv6. See also [RFC8368] for how ACP could be made to interoperate with IPv4 only OAM. Should this include a YANG management protocol like NETCONF? Radius => RADIUS (in a few places) 6.11.1.14. Unknown Destinations As this requirement raises additional Data-Plane, it does not apply to nodes where the administrative parameter to become root (Section 6.11.1.12) can always only be 0b001, e.g.: the node does not support explicit configuration to be root, or to be ACP registrar or to have ACP-connect functionality. The first sentence doesn't quite scan. Nits: retrieved bei neighboring nodes => retrieved by neighboring nodes "serialNumber" contains usually => "serialNumber" usually contains remotely sent IPv6 link-local => remotely send IPv6 link-local _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
