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
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
