Thanks Sheng,
Sorry for the delay, i was working through my queue in order.
See prior reply to Brians review for which i just posted acp-10.
Your review is now top of queue for me and i will quickly triangulate
your -09 comments with -10 and work in your comments for -11.
Cheers
Toeress
On Fri, Sep 01, 2017 at 01:21:25AM +0000, Sheng Jiang wrote:
> 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
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
