Last Call Review of draft-ietf-anima-autonomic-control-plane-13
review-ietf-anima-autonomic-control-plane-13-genart-lc-davies-2018-02-28-00
Request | Review of | draft-ietf-anima-autonomic-control-plane |
---|---|---|
Requested revision | No specific revision (document currently at 30) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2018-02-26 | |
Requested | 2018-02-12 | |
Authors | Toerless Eckert , Michael H. Behringer , Steinthor Bjarnason | |
I-D last updated | 2018-02-28 | |
Completed reviews |
Secdir Early review of -13
by Liang Xia
(diff)
Iotdir Early review of -18 by Pascal Thubert (diff) Rtgdir Telechat review of -13 by Joel M. Halpern (diff) Genart Last Call review of -13 by Elwyn B. Davies (diff) Genart Telechat review of -16 by Elwyn B. Davies (diff) Secdir Telechat review of -16 by Liang Xia (diff) Rtgdir Last Call review of -24 by Joel M. Halpern (diff) |
|
Assignment | Reviewer | Elwyn B. Davies |
State | Completed | |
Request | Last Call review on draft-ietf-anima-autonomic-control-plane by General Area Review Team (Gen-ART) Assigned | |
Reviewed revision | 13 (document currently at 30) | |
Result | Not ready | |
Completed | 2018-02-28 |
review-ietf-anima-autonomic-control-plane-13-genart-lc-davies-2018-02-28-00
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-anima-autonomic-control-plane-13.txt Reviewer: Elwyn Davies Review Date: 2016/02/27 IETF LC End Date: 2016/02/26 IESG Telechat date: (if known) - Summary: Not ready. There are a number of minor issues and a host of nits and editorial fixes needed. I would also consider that the expected status (expeimental vs standards track) ought to be discussed on account of the areas where it is incomplete (e.g., incompleteness of the key Intent mechanism). Major issues: I am sure this has been considered elsewhere, but the amount of future work and areas where operation might discover problems indicates to me that maybe this should be an experimental proposal rather than standards track. Minor issues: Clarity regarding limitations of the ACP approach:The document is relentlessly positive about the ACP approach. Clearly certain problems will not allow the ACP to function. For example it implies that the physical network and interfaces are a shared resource: low level failures or misconfiguration at (say) Level 2, may still knockout the ACP as well as the data-plane. Some brief words on this would not go amiss. This could well be in s4. s2, para 2: There are several instances in the terminology definitions that are confusing before the term has been fully introduced later (and in some cases even then, e.g., the cryptic reference to 'paragraph 21' in the ACP address definition.) This should be cleared up. Notes are given in the Nits/Editorial comments below, s4, "ACP4", also s6.8.2: > Clients of the ACP MUST > NOT be tied to a particular application or transport protocol. It may be that I don't understand the problem, but the communication between the ACP nodes seems to be tied to the secure channels. I am not sure how this is compatible with the any transport protocol requirement. There doesn't seem to be any further explanation of how this requirement is fufilled. This is linked to he means that is not specified by which the ACP address TLS connections are connected to the secure channels. This may be because I don't understand the problem s6.1.1: RFC 5280 discusses the option of leaving the subjectName blank if the subjectAltName is present. What would we expect to find in the subjectName field of the ACP Domain cert? s6.1.1: I don't understand where the routing-subdomain element is carried. routing-subdomain is a top level production in the ABNF that isn't referenced in the rest of the ABNF and a separate example is given. Is the intention that the subjectAltName would consist of a sequence of two rfc822names as allowed by the X.509 syntax if the routing-subdomain is required? s6.1.3: I don't understand why the EST renewal server address has to (or, at least, might) be configured into all ACP nodes when the EST server announces itself with M_FLOOD messages. For one thing it goes (further) against automicity. s6.7.x, Security algorithm agility?: Each of the options specifies a MTI, minimum (in today's tems) capability set of cyypto algorithms. It is not clear (to me) how this will be adapted if and when these algorithms are no longer adequately secure. Some words on ths may be necessary. s9.1, "Network Partition": I am not sure I believe the story on partition - It seems possinle that one of the segments could be left without an enrollment server after partition. Am I right and does it matter? s12: There is no registration policy specified for the new registry created. Nits/editorial comments: General: The style used for introducing acronyms is not consistent with normal RFC style, which is expansion followed by acronym in parentheses, thus... Example (in the Abstract): s/OAM (Operations Administration and Management)/Operations Administration and Management (OAM)/ General: s/e.g.:/e.g.,/ (global) General: In English thequestion mark (?) is not separated by space from the last word in the sentence. There are many instanxes of this problem, especially in s10. Exclusive usage of IPv6: It would be useful to mention (probably somewhere in the last two paras of s1) that the ACP is stricly an IPv6 construct. Abstract and 3 other places: s/out of band/out-of-band/ Abstract: In the last sentence is "not misconfigured" correct? I would have thought it shuld be "misconfigured". s1, para 1: The phraseology "currently being defined in the document" for the reference model is not future proof. Replace with "specified in". s1, para 3: A construct cannot 'run' in a table: OLD: runs in the global routing table NEW: runs over the network defined by the global routing table END s1, para 3: s/to recover/to avoid or allow recovery/, s/personnel is/personnel are/ s1,para 6: s/data-plen/data-plane/ s1, para 8: Expand GRASP on first occurrence (the terminology definitions come in s2). s1, para 13 (2nd para on page 6): Suggest s/without dependency against/without reliance on/ s1, next to last para: s/It also explains on how existing management solutions/It also explains how existing management solutions/ s1,last para: s/with full secure/with fully secure/, s/[I-D.ietf-anima-reference-model]. which/[I-D.ietf-anima-reference-model], which/ [period ->comma], s/it enables building more/it allows the building of more/ s2: There are a few terms that have special meaning within the context of the document (e.g., data-plane, loopback interface) which do not use capitalized names. It might be helpful to globally change the names to (eg.) Data-plane Loopback interface where the special meaning is implied. s2: It would be useful to note the terms imported from RFC7575. s2, para 2: ADD: Note that definitions may contain terms that are defined later in the list as a result of the alphabetic ordering. END s2, "ACP": The term "zero-touch" is jargon that may not be understood by non-English mother tongue readers. Please add a definition or expand it here. s2, "ACP address": The term "ACP domain certificate" probably needs a definition - this would then point to the RFC that defines the certificate type used and hence allow the reader to locate the domain information field. I am unclear what "(paragraph 21)" refers to - is this terminology used in the certificate type? s2, "ACP connect": For consistency this should be "ACP connect interface". s2, "ACP secure channel protocol": Expand IKEv2, dTLS.(IPsec is well-known). s2, "ACP (ULA) prefixes": Given that ULA is a term defined in RFC 4193, I would be inclined to expand on first use (here) and refer to the RFC rather than part duplicating the formal definition further down. s2, "data-plane": s/In a full Autonomic Network node/In a fully Autonomic Network node/ s2, "Intent": The term 'Northbound' is a piece of jargon that is not well-known outside the SDN community. This is the only usage in the document. Please expand it here. s2, "RPL": Please add the ref to RFC 6550 here. s2, last para: Given the last sentence, change RFC 2119 -> RFC 8174. s3.3, para 1: s/(global routing table)/using the global routing table/ [See comment on s1, para 3 above] s3.3, para 2: s/unreachable can lock/unreachable or can lock/ s3.3, para 4: s/allows control plane and management plane/allows the control plane and the management plane/ s4, "ACP3": s/suggests to use/suggests using/ s5, bullet #5: > each node sets up a loopback interface with > its ULA IPv6 address. Given the way the IPv6 loopback interface works, this might be better described as "adding the ULA IPv6 address to the loopback interface" - there is only ever one IPv6 loopback interface per device or VRF. s6, para 2: What certificate must it have? (the ACP domain cert according to s6.1.) s6.1, para 3: OLD: Those IDevID do not include owner and deployment specific information to allows autonomic establishment of trust for the operations of an ACP domain NEW: A IDevID does not include owner and deployment specific information that would allow autonomic establishment of trust for the operations of an ACP domain END s6.1, para 4: The term 'its reference document is unclear. I guess it means RFC 7575. OLD: This document uses the term ACP in many places where its reference document use the word autonomic. This is done because those reference document consider fully autonomic network and nodes, but support of ACP does not require support for other components of autonomic networks. Therefore the word autonomic would be irritating to operators interested in only the ACP: NEW: This document uses the term ACP in many places where the Autonomic Networking reference model document [RFC7575] uses the word "autonomic". This is done because those reference model document considers fully autonomic network and nodes, but support of ACP does not require support for other components of autonomic networks. Therefore the using just the word "autonomic" might be confusing to operators interested in only the ACP: END s6.1.1, title: s/Field/Fields/? Not sure if this is better? s6.1.1: Turn RFC 1034 into a proper reference to shut up idnits. s6.1.2, bullets #2 and #4: s/peers/peer's/ s6.1.2, bullet #3:Expamd CDP, OCSP and CRL - not in RFC editor well-known list (and indeed CDP as used here is not in the list at all.) s6.1.3: Point to Section 2.8.11 of the GRASP draft for the flood message definition. s6.1.3: Expand CDDL on first occurrence. s6.1.3, top of page 20: So high? Surely 'sufficiently low'? OLD: It must be so high that the aggregate amount of periodic M_FLOODs from all flooded objectives causes only negligible traffic across the ACP. NEW: The frequency of sending MUST be such that the aggregate amount of periodic M_FLOODs from all flooding sources causes only negligible traffic across the ACP. END s6.1.2, para 2: s/directly adjacent/diectly adjacent (i.e., not on a link connected to this node)/ s6.1.3: To make the introduction of BRSKI at the end of Section 6.3 more comprehensible, it would be useful to explain that the initial domain certificate can possibly be installed using BRSKI or some other mechanism rather than by out-of-band configuration as set out in the BRSKI draft. Alternatively this could be part of s5, the overview. s6.1.3, next to last para: s/primarily/primary/ s6.2, para 1: The term Node-ID should probably be in the terminology section. Either that or it needs to be explained here s6.2, para 2: s/node-ID/Node-ID/ s6.3: It would be helpful to reinforce that this part of the operation (and the reason for the existence of DULL GRASP) is that it operates on an unsecured channel - otherwise the appearance of DULL is unexplained. DULL should be expanded on first use. s6.3, para 1: The DULL section in the GRASP draft is now s2.5.2. s6.3, para 1: Expand SLAAC on first use. Maybe refer to RFC 4862. s6.3, para 2: Since RFC3810 is referenced. is MLDv2 REQUIRED (not sure if MLDv1 is still implemented ever)? s6.3, para 3: s/how to enable/on how to enable/ s6.5, paras 2-4: Para 2 ends with a colon: It maybe that the original intention was to format the next two (?) paras as bullet points introduced by para 2. If so then adjust the formatting of paras 3-4; otherwise change the colon to a period. s6.5, para 3: Need a reference for MacSec and probably an expansion of the name - I presume this is referring to IEEE 802.1AE. s6.5, paras 5-8: As above para 5 ends with a colon. It seems that there are two rules to enumerate after this - para 6 and paras 7-8. If so arrange these paras as two bullet points. Otherwise the wording of para 5 needs altering. s6.5, para 6: s/itmust be used/they must be used/ s6.6, "(with throttling)": Some greater precision is needed here. s6.8.1, para 1: OLD: They function in GRASP that makes it fundamental as a service is the ability for ACP wide service discovery (called objectives in GRASP). NEW: The function in GRASP that makes it fundamental as a service is the ability to provide ACP wide service discovery (using objectives in GRASP). END s6.8.1, para 2: s/described below/see Section 6.11/ s6.8.1, para 3: s/in the following section/in Section 6.8.2/ s6.8.1, para 4: s/original form/the original form/ s6.8.1, para 4: s/that has never been attempted to be solved/where no attempt at a solution has been described/ s6.8.1, para 5: s/Future ASA/A future ASA/, s/These ASA/Such an ASA/ s6.8.1, para 6: The concept 'constrained flooding' used here for M_DISCOVERY messages is not defined either in this document or the GRASP draft. This needs to be explained more cearly. s6.8.1, para 4: Expand PIM-SM. s6.8.2, para 2: s/responsible to ensure/responsible for ensuring/ s6.8.2: > [RFC Editor: please try to put the following picture on a single page > and remove this note. We cannot figure out how to do this with XML. > The picture does fit on a single page.] Layout hints: You can get an extra 9 lines for the figure by - Moving the heading ACP: either to the left of the first line or put it as part of the title (which you haven't specified as yet) so it doesn't need a line to itself. - Removing 2 essentially blank lines (the second line and the line above ACP-loopback Intetf. - Forcing a page break after the paragaph above the figure - Removing the RFC Editor note. Assuming you are using xml2rfc v2, insert the Processing Instruction PI <?rfc needLines="46" ?> above the figure text (assuming I have counted right). I think it will then fit on one page. s6.8.2.1, para 4: s/the semantic of the GRASP negotiation to an extend/the semantics of the GRASP negotiation to an extent/ s6.9, para 1: s/ACP channels/ACP channels'/ s6.9, para 2: s/systems/system's/ s6.10.1, last bullet: s/no not/do not/ s6.10.2, bullet #3: Expand CSR. s6.10.3, next to last para: s/allows to easily add/allows the easy addition of/, Expand SW. s6.10.3, last para: s/allows to announce/allws the announcement of/ s6.10.4, next to last para: s/The Z field is following/The Z field follows/ s6.10.5, bullet #1: s/use via/that might be used/ s6.10.5, bullet #2: s/allows to use/permits the use of/ s6.10.6, last para: s/should consider to be extensible in itself/should consider making provision for further extensions/ s6.11.1.1, para 1:s/reasonable fast/with reasonably fast/ s6.11.1.1: Expand DODAG, NOC, RPI, RPPL on first occurrence. ( or is it s/RPPL/RPL/?) s6.11.1.4: Expand DAO on first occurrence. s6.11.1.11, last para: s/is avoid/is to avoid/ s6.11.1.12: Expand DIO. s6.12.2, para 1: s/only specify/only specifies/ s6.12.3, para 2: s/to be prioritize/to prioritize/ Reviewer note: There are a rather smaller density of nits in s7 and s8 - I have run out of time to record them at this point. If it is useful I can forward notes separately in a few days time. s10, para 1: s/cope/scope/ s10.2: expand LLDP on first occurrence. May need a reference. s10.3.2.2: Expand BFD on (only) occurrence. May need a reference. s10.4.1: Expand CDP on firat occurrence. s10.4.2: Expand mDNS and DNS-SD on first occurrence. s10.5: This Appendix explains why RPL > This Appendix explains why RPL... S10.5 is not an appendix (although aguably the whole of s10 should be an appendix.). s12, paras 5 and 6: These are duplicates. Remove one! s15.2: I think some of these references are normative: especially ietf-anima-reference-model, ietf-roll-useofrplinfo, RFC 6553, RFC 5234