Somehow, I don't know how, I misspelled the name of the draft. Resend my review comments with the right name in title and to the right authors alias.
Sheng From: Anima [mailto:[email protected]] On Behalf Of Sheng Jiang Sent: Thursday, August 31, 2017 7:01 PM To: [email protected] Cc: [email protected] Subject: [Anima] Review on draft-ietf-anima-auotnomic-data-plane-09 Hi, authors of draft-ietf-anima-auotnomic-data-plane, I am doing a thorough review as the document shepherd with my ANIMA chair hat on. Please address the below comments so that we could process this document further. This is a petty long document. Therefore, my review may be a little bit disordered. Overall, I think this document has been in a good sharp although I cannot claim all my comments are minor. I believe they are not difficult to address. In introduction section, it is better to reference the "Autonomic Control Plane" definition & description in Section 5 of RFC7575, rather than "[RFC7575] calls it the 'Autonomic Control Plane'" . The ACP could actually be communication channel for both management and control plane. So, the name seems be mis-leading. My understanding is that we could not change the name in such late stage. But it worth to see more on this in the introduction, even in the abstract. "This document describes options for a ... ACP". I am confused by the word "option". What option does it actually mean? At least, it is not clear from the context. "It therefore remains operational even in...". My understanding for "it" is the network, but from the context, my first expression for "it" is ACP. Used short for the first appearance, ANI, VRF, IKE, TLS/dTLS, SDN, NOC, OAM, NMS, CA and although GRASP, BRSKI, EST, ULA, are defined in Section 2, but their first appearance is before their terminologies. Section 2, "ACP provides secure zero-touch network wide IPv6 connectivity between devices supporting it." This is not accurate. These two devices must be in the same autonomic network. Actually, we did not define an important concept yet - the domain of autonomic network. We were always assume there is only one domain within the connectivity range or the autonomic network would naturally be separated by non-AN devices. But it would not always be the case if AN technologies become widely deployed In Section 3, "certain AAA misconfigurations can lock an administrator out of a device", I am not sure how ACP helps in this use case. It seems for me the only way is to log in with another admin account, then change the misconfig. It is no different through normal data plane. This can still be recovered remotely without ACP. "The ACP provides reachability that is largely independent of the data plane." Why "largely"? It implies that is still partially (maybe small proportion) dependent on the data plane. "ACP MUST NOT be tied to a particular protocol." ACP does need support from some specific protocol, GRASP, IPv6. I am sure you did not mean them. But the description should be improved to be more precise. "The ACP MUST provide security". I am not sure the "MUST". In many scenarios, for example, some layer has very strong layer 2 security mechanism, or network with physics isolation/protection. The connectivity is the vital functionality that ACP could provide, while security provided by ACP is redundant or not necessary. "The default mode of operation of the ACP is hop-by-hop." I guess you mean "basic" or "fundamental" rather than "default". The multiple connectivity is made up by hop-by-hop connections. " ULA "Unique Local Address". The IPv6 equivalent to RFC1918 IPv4 addresses. ACP addresses are ULA."Please don't consider ULA as an equivalent to RFC1918. We used to have relevant discussion in v6ops WG, and people had strong consensus on ULAs != RFC1918. (see https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations-02#section-3.1) The content of section 3.3 reads like the essential benefit rather than a specific use case, especially comparing to Section 3.1 and 3.2. More proper place for this may be Section 9 (Benefits). "ACP loopback interface" and "ACP virtual interface" refer to different things as defined in the Terminology section. However, in the main text, sometimes they are mixed together ((E.g. in section 5, Item 5 and 6). Either they should be used in a canonical way in this document, or other more distinguished terminologies should be used to refer the two things. The terminology "ACP connect" same not proper. It would be more proper to call the connect/channel for non-ACP device joining the ACP through an ACP device "ACP bridge"? In section 6, Initially, it must have a ... as well as an adjacency table."The word here is misleading. The authors should mean the functionality of an adjacency table. But it reads like an adjacency table with already learned neighbor information. Inadvert -> inadvertent The term "Autonomic Domain" first appears at section 6.1, it should be defined in section 3. acp-address within ACP information should be optional. It may be the address is generated by AN after getting the domain certificate. It is worthy to clarify that although the LDevID contains ACP-information, it is not specific for ACP only; it is generic for other functions that request node-level authentication. "To establish an ACP securely, an ACP device MUST have a globally unique domain certificate (LDevID)"I think the requirement in this sentence is too strong in two perspective: why globally unique, secondly it is not necessary to be a domain certificate that newly assigned in this domain. Furthermore, this seems imply ACP depend on BRSKI as pre-step, which I don't think is in authors original meaning. "The ACP network MUST have one or more nodes that support EST server through which ACP nodes can renew their domain certificate." The work "MUST" is far too strong here. "it should choose am FQDN" -> it should choose "an" FQDN "The format of the rfc822Name is choosen" -> The format of the rfc822Name is "chosen". There are another 4 instance of "choosen". "The loop-count MUST be sete to 255" -> The loop-count MUST be "set" to 255 "When it is time for domain certificate reneal" -> When it is time for domain certificate "renewal" "the primarily imiting factor for shorter certificate lifetimes", my guess is "limiting" "the assigning CA has enough performance" -> the assigning CA has enough "performance" "See Section 10.1 for further optimizationss" -> See Section 10.1 for further "optimizations" The first sentence of section 6.3, "Because of the the considerations", the second "the"should be deleted "ACP discovery MUST NOT be enabled by default on any non-physical interfaces." This seems rule out the possibility of applying ACP with virtual devices. My suggestion would be deleted the sentence since we ready have the follow up sentence "ACP discovery MUST NOT run inside the ACP." Or not deleting, we should at least soften it to be "SHOULD NOT". Section 6.5, "the next step after discoving" -> the next step after "discovering" "The roles of Bob abd Alice" -> The roles of Bob "and" Alice "It is not up to Alice to devide" -> It is not up to Alice to "divide" "interfaces are the ame devices" -> interfaces are the "same" devices Section 6.6, "certificate must be valid occording to"-> certificate must be valid "according" to Section 6.7, "the ACP secure channel protocol" -> the ACP secure channel "protocol" "ACP mechanisms they support" -> ACP mechanisms they "support" "ACP secure channel MUST imediately be terminated" -> ACP secure channel MUST "immediately" be terminated "Note that is is not standard behavior" -> Note that is not standard behavior Section 6.8, "Authentication is via the the domain" -> Authentication is via the domain Section 6.10, "65536 different virtualized adddresses" -> 65536 different virtualized "addresses" Section 6.11, on-RPL-aware leafs (or "Internet") accoding to -> on-RPL-aware leafs (or "Internet") "according" to "the ACP will only accommodate" -> the ACP will only "accommodate" Routeable - > routable; at least two instances "The multi-access ACP virtual interace" -> The multi-access ACP virtual "interface" Thanks for your hand work and good contribution to the ANIMA group. Regards, Sheng
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
