Re: [Gen-art] Gen-art LC Review of draft-ietf-anima-autonomic-control-plane-13
Toerless Eckert <tte@cs.fau.de> Wed, 06 June 2018 20:42 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA90130F94; Wed, 6 Jun 2018 13:42:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.941
X-Spam-Level:
X-Spam-Status: No, score=-3.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBDKJsOVP3vq; Wed, 6 Jun 2018 13:42:27 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2DA3130FD6; Wed, 6 Jun 2018 13:42:26 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C931C58C4C4; Wed, 6 Jun 2018 22:42:21 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id BCDC84401A4; Wed, 6 Jun 2018 22:42:21 +0200 (CEST)
Date: Wed, 06 Jun 2018 22:42:21 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Elwyn Davies <elwynd@dial.pipex.com>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, draft-ietf-anima-autonomic-control-plane.all@ietf.org
Message-ID: <20180606204221.hakngihjkynmdot6@faui48f.informatik.uni-erlangen.de>
References: <a6351b48-ae97-5212-58cb-40a1f242fafb@dial.pipex.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <a6351b48-ae97-5212-58cb-40a1f242fafb@dial.pipex.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/TXwucgjWbpfC0q_1Ga0Y7SQOYOY>
Subject: Re: [Gen-art] Gen-art LC Review of draft-ietf-anima-autonomic-control-plane-13
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jun 2018 20:42:37 -0000
Hi Elwyn, * Sorry for the long delay. Somehow i ended up working through the reviews in stack, not in timeline order, and the excellent review from Joel Halpern had me do more than i was hoping for. But as i hope all for the better of the document. But together with business travel etc. it did delay this feedback to your review a lot. Sorry. I forgot to commit an intermediate version working through your comments before the nits, but this response mail does include copies of the changed texts for those changes anyhow. I did create a version before working on the nits, so here is the diff created for your nits. http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14-jh3.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/f9b00048946af77d8b716ec4c9e28e1d6a95b455/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt Rest Inline. Thank you very much & keep it coming! Cheers Toerless On Wed, Feb 28, 2018 at 02:24:09AM +0000, Elwyn Davies wrote: > 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). Wrt standard track: ACP was targeted from day 1 of ANIMA charter to be standards track. Experience with existing implementations and the technologies used by ACP make this IMHO very appropriate. All the protocol mechanisms required for and used by the ACP are well defined and their interactions (i hope) are well specified in the normative sections of the ACP document. ACP design is actually quite conservative, leveraging mostly well known technologies/protocols, just combining them in a much more automated way than prior solutions. The only significant new protocol the ACP uses is GRASP, which also targets standard track, and which was developed with ACP as a use-case in mind to solve problems with prior, IMHO more complex protocols. We also have a range of implementations ranging from commercial/production over to experimental/open-source. > 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. Wrt future work: Maybe there is a misunderstanding. The term "future work" in the ACP draft is not meant to indicate things that need to be resolved in this document before it can become RFC or that limit the ability of the ACP to support the use cases it it designed for. All references to "future work" are informational. They refer to features considered valuable during WG work, but did not make the cut when we defined the minimum viable product for ACP (which is now its MUST/SHOULD/MAY). During chartering, ANIMA was asked by the AD to NOT work on pure architecture documents, but concentrate on specification. During the resulting WG work, it became obvious that its hard to make the community understand the overall system design without being more explanatory and that includes extensions and interactions with future components like Intent. So a good amount of explanatory text including mentioning of futures is a stand in for not having another document to discuss more in-depth background information on a novel system design. If it helps, i am happy to change "future work" to "future documents", but "future work" is the most popular term in existing RFCs. Wrt intent: ANIMA charter so far is to define ANI: ACP,GRASP,BRSKI as a common infra for non-autonomic and future autonomic networks. Intent is only a part of envisioned future autonomic networks, so Intent is not necessary to use ACP/ANI in todays networks. It is mentioned in ACP primarily so that future work for Intent understands how ACP would like to use Intent itself if/when it is available. Specifically the issue of designing it so circual dependencies with ACP are avoided/resolved. Wrt: "operation might discover problems" Simple answer ? The ACP is very simple to operate, the suggested operational considerations in the draft are quite limited but IMHO very important. Ranting answer ? I really frightened by this comment, because i think it can encourage the bad habbit of ignoring or at least not documenting operational aspects of solutions in RFCs to make them look better. Especially when many existing solutions are extremely difficult to manage: "Nerd knob heaven - SDN controller to the rescue" With ACP we do attempt to do the opposite: Make it as easy to operate as possible and document the remaining operational aspects well to accelerate adoption based on our pre-standard implementation experience I can only guess what specifically you are referring to, because you did not specify it: Section 10.2 discusses desirable/suggested diagnostics and -14 new section 10.3 desirable configuration (for registrars). These sections are intended to be precursors/suggested requirements to future YANG models specifying the operator interface to the ACP. I have developed, deployed and operated a commercial ACP implementation. The operator interface aspects discussed in 10.2/10.3 are from reflection of that experience. Diagnostics for implementation issues and operator mistakes, smallest number of nerd knobs that we think would make the solution low-opex and by minimizing the opportunity for operational mistakes. To put this into perspective: I have also designed, developed or operated a range of enterprise VPN technologies/solutions (including their PKI), all of which are widely used and deployed and use standard IETF protocols and IETF standard PKI crypto. That stuff is IMHO orders of magnitude more complex than ACP, full of nerd-knobs and IMHO very error prone (did i say SDN controller to the rescue ?). Yet you will not find any good IETF specifications of most operational aspects of these solutions exposing their complexity (diagnstics, config CLI, better automation, ...). Aka: The amount of suggested operational interfaces to manage the ACP as discussed in 10.2/10.3 is very small compared to what you would need to document to support the same degree of implementation and operator issue diagnostics and configuration for any of the pre-existing IETF standard based system solutions leveraging similar technologies (PKI, encryption, VPN, VRF,...) > 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. Wrt. "relentlessly positive" Please point me to specific places you consider to be "relentlessly positive" ? I will be happy to re-word them factually. Wrt. implementation options Unlike the documentation of operator interfaces discussed above, that i am adament to include in the specification we choose not to include any of this implementation specific discussion because it really does not fit into this document (IMHO): We have prototyped, productized or brainstormed a wide range of implementation options. Neither of them is really short to document or IMHO appropriate for this document, but they all impact the degree of solving local, non-interoperability issues you mention. Instead, 10.2/10.3 specifically limits itself to discussing issues we hope are independent of implementation choices. I would love to find the time to write an informational document discussing principle implementation alternatives and their pro/cons because i think some of them are also quite fundamental for how to design network OS software and could equally find applicability in other longer term IETF relevant network SW architectures, like slices or virtual routers. I am actually relentlessy negative about some well-understood implementation options for exctly the reasons you mention. But i am likewise relentlessly positive about implementation options that would solve these issues. And yes, i think there are feasible implementation options to make the ACP fully resilient against the issues you mention with the right implementation option. If you're not persudaded to leave such implementation discussion for other work, maybe we can take it offline. I do not want to drag this on too much in this thread. > 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, I am not a big fan of cross-referencing between terms defined in the terminology section. Not only because i think its somewhat obvious that if you don't know a word, you gotta look it up in *doh* the terminology section, but also because the tooling we have with our XML really sucks for this problem. That paragraph 21 was my first attempt to create a cross reference into another term defined in the terminology section and it failed as you saw. I've figured out a better way in -14 (see ACP domain certificate), but its very cumbersome trying to create these for all terms where the XMl tooling should really make this a lot easier. I've left myself a breadcrumb to disuss this with RFC editor. So, if you have specific enumerated terms you see, please tell me, i'll do the chores, but let me try not to have to do it for all of them unnecessarily. > 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 Hah. So this whole section was basically the result of a long discussion during initial ANIMA work about our self-defined requirements (before chartering if i remember right). The initial argument was made that ACP just needs to provide resilient GRASP connectivity between nodes because all AN will use is GRASP. Then we started to include the need to support non-AN networks with ACP as well and ACP4 was written to effectively argue that ACP needs to provide IPv6 connectivity. I think you're something like the third reviewer or so whom i have to explain this, so i finally dared to add the explanation to this requirements chapter that i really didn't want to touch, because its like the five commandments to the ACP. <t>Explanation for ACP4: In a fully autonomic network (AN), newly written ASA could potentially all communicate exclusively via GRASP with each other, and if that was assumed to be the only requirement against the ACP, it would not need to provide IPv6 layer connectivity between nodes, but only GRASP connectivity. Nevertheless, because ACP also intends to support non-AN networks, it it is crucial to support IPv6 layer connectivity across the ACP to support any transport and application layer protocols.</t> Not sure about your confusion about TLS. There is no linkage between any end-to-end security connections and they ACP. The ACP just blindly hop-by-hop encrypts to protect the ACP infra. So there is what looks like duplication of security effort, but end-to-end and hop-by-hop security really serve two complementary purposes even though the hop-by-hop encryption also stands in for missing end-to-end encryption of legacy OAM protocols. I thought i also wrote that somewhere in the doc. > 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? "I don't know and ACP does not care" ACP only cares for the subjectAltName email address carrying the ACP domain information. No other field is required to be present in the cert to pass the mutual ACP domain cert authentication. As far as ACP is concerned, subjectName could be empty. We did choose this so we would not step on any subjectName a cert might want to have if its used dual-purpose for ACP domain authentication and any other auhentication that may pre-exist on the device. So in all likelyhood, the subjectName will include whatever a standard cert on a device includes and it just also includes the ACP domain information field. Let me know if i am missing any explanation. I thought i'd already explained everything possible for the section. > 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? So we need a domain like acp.ietf.org for domain authentication and we may want multiple subdomains like bla.bla.acp.ietf.org and whatever.else.acp.ietf.org if we want to segment routing in the future. We can not simply encode as ...@bla.bla.acp.ietf.org because we wouldn't know what the domain part of this is. ietf.org ? bla.acp.ietf.org ? both wrong. So we encode the subdomain prefix rsub in the local part ....+bla.bla@acp.ietf.org. Then we have the ABNF definition of routing subdomain and thats what we refer to for the ULA hash calculation later in the doc because that creates different IPv6 prefixes and those different prefixes would allow easy aggregateable routing areas. Please let me know where wee lost you in explaining how it work. Best with suggested text improvements. > > 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. The explanation is further below in the text: stickyness for easier diagnostics, reduced attack vector. I also wanted to have at least one deterministic selection mechanism, and i had to drop the more intelligent ones like priority or vicinity based, because we'd first need to get better service parameters for GRASP standardized (draft-eckert-anima-grasp-dnssd) (too much work for just a one-off definition in the ACP spec). There is no relevant additional manual work needed to store/remember the prior EST server though. But the text wasn't well written. here is whats in -14: <t>ACP nodes SHOULD be able to remember the EST server from which they last renewed their ACP domain certificate and SHOULD provide the ability for this remembered EST server to also be set by an ACP Registrar (see <xref target="acp-registrars"/>) that initially enrolled the ACP device with its domain certificate. When BRSKI is used for certificate enrollment, the ACP address of the BRSKI Registrar from the BRSKI TLS connection SHOULD be remembered and used for the next renewal via EST if that Registrar also announces itself as an EST server for renewal via GRASP (see next section) on its ACP address.</t> Aka: Can be fully automatic when BRSKI is used. And also IMHO with any other automated mechanism. And just because the ACP node SHOULD support it doesn't mean that some Registrar SHOULD use this option !!! > 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. Good question. I have no idea what the best statement/text would be to comply with the IETF BCP for crypto agility. In fact: is there any such BCP and what is its number ? I am only aware of this one draft retrofitting static session keys into IKEv2 to overcome the quantum attacks against RSA/ECC functions like DH. If you can not suggest text, i was trying to wait for SEC review to resolve this issue. Unless i stumble into simple example text earlier that SEC AD would like. > 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? Hah, thank you. I had to write a bunch of new text about ACP Registrars for -14 after Joel Halperns review and seeing it as a big gap in the text. He was also complaining about our addressing scheme, so i wanted to outline in more detail how the addressing (and its "waste" of 48 bit of address space for Registrar-IDs) related to the desire to also support highly resilient distributed solutions. Section 10.3.4 describes now the example of distributed registrars with integrated sub-CA. I added the following to 9.1: <t>Highly resilient ACP designs can be built by using ACP registrars with embedded sub-CA, as outlined in <xref target="sub-ca"/>. As long as a partition is left with one or more of such ACP registrars, it can continue to enroll new candidate ACP nodes as long as the ACP registrars sub-CA certificate does not expire. Because the ACP addressing relies on unique Registrar-IDs, a later re-merge of partitions will also not cause problems with ACP addresses assigned during partitioning.</t> Relentlessly positive! > s12: There is no registration policy specified for the new registry created. Hmm.. MUST be assigned using the Standards Action policy defined by <xref target="RFC8126"/>. But the paragraph requesting creartion of the registry was duplicated. Maybe that confused you. Fixed. ------------------------------------------------------------------------ > Nits/editorial comments: Reply syntax: Gone - Requested fixes had been applied through prior -14 fixes A&A - Asked & Answered (above) > 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)/ Ok. Hope i found & fixed all instances of this. > General: s/e.g.:/e.g.,/ (global) Done. > 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. Done. > 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. Resolved via new section 1.1 "Applicability and Scope" introduced as result of another review into -14. > Abstract and 3 other places: s/out of band/out-of-band/ Done. > Abstract: In the last sentence is "not misconfigured" correct? I would > have thought it shuld be "misconfigured". Done. > s1, para 1: The phraseology "currently being defined in the document" for > the reference model is not future proof. Replace with "specified in". Done > 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 Fixed as "uses the global routing table" (scared of trying to defend what "network defined by" would mean, given how inconsistent this can be from different viewpoints). > s1, para 3: s/to recover/to avoid or allow recovery/, s/personnel > is/personnel are/ Done > s1,para 6: s/data-plen/data-plane/ Gone > s1, para 8: Expand GRASP on first occurrence (the terminology definitions > come in s2). Done > s1, para 13 (2nd para on page 6): Suggest s/without dependency > against/without reliance on/ Gone > s1, next to last para: s/It also explains on how existing management > solutions/It also explains how existing management solutions/ Gone > 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/ Done > 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. Done for these two terms. But i am still not sure about explicit rules for capitalization. Any good reference/rules you could point me to ? > s2: It would be useful to note the terms imported from RFC7575. I would rather not do this. The problem is that the ACP draft started out assuming an autonomic network like RFC7575 does so it used all autonomic/AN-* terms, and over time and many reviews it became clearer that we should avoid any autonomic network terms because they would often raise the confusion that the ACP requires a full autonomic network (the few cases of Intent being the last leftovers). In the last revisions i did therefore changed most AN-* terms into ACP-* terms to make it a lot clearer that there is no dependency against (especially undefined) AN components, and that ACP is really standalone. Last one was in -14 the definition of ACP Registrar as a superset of of BRSKI Registrar and any other possible Registrar meeting the now defined ACP Registrar requirements. > 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 A&A > 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. Let me partially punt this to BRSKI because thats the doc really responsible for this. Today it just says "zero-touch (automated)", so i also added that parenthesis explanation. The first use of zero-touch also refers to BRSKI as providing it. > 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. Term was defined but not correct in order. Fixed. Fixed to say RFC5280 certificate. > I am unclear what "(paragraph 21)" refers to - is this terminology > used in the certificate type? A&A > s2, "ACP connect": For consistency this should be "ACP connect interface". Done > s2, "ACP secure channel protocol": Expand IKEv2, dTLS.(IPsec is well-known). Done. > 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. Actually, RFC4193 uses the word Prefix in its section 3.1 to refer to the 7 bit IPv6 address prefix identifying the ULA address space. But does not call it "ULA Prefix". And it doesn't define a term for the /48 prefix that we need to refer to. So we've used in my memory in ANIMA and at work the term ULA Prefix always to refer to the /48 prefixes in the ULA space, and thats why i want to keep that definition. Unless someone tells me a better way to solve the issue of how to refer to the /48 prefixes. Which is what we want to do. > s2, "data-plane": s/In a full Autonomic Network node/In a fully Autonomic > Network node/ Done > 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. Gone > s2, "RPL": Please add the ref to RFC 6550 here. Gone > s2, last para: Given the last sentence, change RFC 2119 -> RFC 8174. Done > s3.3, para 1: s/(global routing table)/using the global routing table/ [See > comment on s1, para 3 above] Done > s3.3, para 2: s/unreachable can lock/unreachable or can lock/ Done > s3.3, para 4: s/allows control plane and management plane/allows the control > plane and the management plane/ Done > s4, "ACP3": s/suggests to use/suggests using/ Done > 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. Changed to "Inside the ACP VRF, each node assigns its ULA IPv6 address to a Loopback interface assigned to the ACP VRF" On the router OS you can have multiple loopback interfaces, so do not want to presume three is only one. > s6, para 2: What certificate must it have? (the ACP domain cert > according to s6.1.) fixed to "must have its ACP domain certificate" > 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 Gone > 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 Done (also referring to reference-model draft beside 7575). > s6.1.1, title: s/Field/Fields/? Not sure if this is better? Specifies single instance, so Field should be fine. > s6.1.1: Turn RFC 1034 into a proper reference to shut up idnits. Don't know how to do it inside a figure. Changed to "RFC 1034" for the time being in hope to shut up idnits. If you don't have an idea, then its a job for RFC editor. > s6.1.2, bullets #2 and #4: s/peers/peer's/ Done > 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.) Gone > s6.1.3: Point to Section 2.8.11 of the GRASP draft for the flood message > definition. Done > s6.1.3: Expand CDDL on first occurrence. Done. Also added missing reference. > 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 Done > s6.1.2, para 2: s/directly adjacent/diectly adjacent (i.e., not on a link > connected to this node)/ Done > 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. There is now a lot more text about Registrars and BRSKI in -14, so i do not want to add more in random places like this, but fixed up the sentence, but fixed up sentence to read easier: Note: If an ACP node also implements BRSKI to enroll its ACP domain certificate (see <xref target="bootstrap"/> for a summary), then the above considerations also apply to GRASP discovery for BRSKI > s6.1.3, next to last para: s/primarily/primary/ Done > s6.2, para 1: The term Node-ID should probably be in the terminology > section. Either that or it needs to be explained here Done Added definition to terminology and explanation her: (identifier of the node inside the ACP, see <xref target="zone-scheme"/> and <xref target="Vlong"/>) > s6.2, para 2: s/node-ID/Node-ID/ Done > 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. Done DULL GRASP is a limited subset of GRASP intended to operate across aninsecure link-local scope. See section 2.5.2 of <xref target="I-D.ietf-anima-grasp"/> for its formal definition. The ACP uses one instance of DULL GRASP for every L2 interface > s6.3, para 1: The DULL section in the GRASP draft is now s2.5.2. Gone (fixed be above). > s6.3, para 1: Expand SLAAC on first use. Maybe refer to RFC 4862. Done > s6.3, para 2: Since RFC3810 is referenced. is MLDv2 REQUIRED (not sure if > MLDv1 is still implemented ever)? Done ...to use Multicast Listener Discovery Version 2 (MLDv2, see <xref target="RFC3810"/>) Funny how RFC editor recognizes IGMP as well-known in its abbreviations, but MLD not. Wrt. proto rev requirement, see my post on pim@ietf.org triggered by this nit. Technically, MLDv1 would suffice in this case. > s6.3, para 3: s/how to enable/on how to enable/ Done > 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. Done Changed to period. Only following paragraph explains what the colon meant to emphasize, so single bullet wouldn't look good... i think. > 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. Done > 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. Done Created list. > s6.5, para 6: s/itmust be used/they must be used/ Done > s6.6, "(with throttling)": Some greater precision is needed here. Done Attempts to reconnect MUST be throttled. The RECOMMENDED default is exponential backoff with a a minimum delay of 10 seconds and a maximum delay of 640 seconds. > 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 Done > s6.8.1, para 2: s/described below/see Section 6.11/ Done > s6.8.1, para 3: s/in the following section/in Section 6.8.2/ Done > s6.8.1, para 4: s/original form/the original form/ Done > s6.8.1, para 4: s/that has never been attempted to be solved/where no attempt at a solution has been described/ Done > s6.8.1, para 5: s/Future ASA/A future ASA/, s/These ASA/Such an ASA/ Done (used "Some" instead of "A"). > 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. Done which are intelligently (constrained) flooded not across the whole ACP, but only up to a node where a responder is found Btw: This is not anything new, just reciting what GRASP specifies. GRASP may not have phrased a term like "constrained" for it though. > s6.8.1, para 4: Expand PIM-SM. Done > s6.8.2, para 2: s/responsible to ensure/responsible for ensuring/ Done > 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. Gave up after 45 minutes. needLines not working for me yet. Posted question to xml2rfc@ietf.org > 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/ Done > s6.9, para 1: s/ACP channels/ACP channels'/ Done > s6.9, para 2: s/systems/system's/ Done > s6.10.1, last bullet: s/no not/do not/ Gone > s6.10.2, bullet #3: Expand CSR. Done > 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/ Done > s6.10.4, next to last para: s/The Z field is following/The Z field follows/ Gone. > s6.10.5, bullet #1: s/use via/that might be used/ Gone > s6.10.5, bullet #2: s/allows to use/permits the use of/ Done > s6.10.6, last para: s/should consider to be extensible in itself/should > consider making provision for further extensions/ Done > s6.11.1.1, para 1:s/reasonable fast/with reasonably fast/ Done > s6.11.1.1: Expand DODAG, NOC, RPI, RPPL on first occurrence. ( or is it > s/RPPL/RPL/?) Done > s6.11.1.4: Expand DAO on first occurrence. Done > s6.11.1.11, last para: s/is avoid/is to avoid/ Gone > s6.11.1.12: Expand DIO. Done > s6.12.2, para 1: s/only specify/only specifies/ Rejected The fully autonomic mechanisms in this document only specify Its mechanisms, so it should be specify, not ? > 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. Please do so, your thoroughness is greaT! > s10, para 1: s/cope/scope/ Done > s10.2: expand LLDP on first occurrence. May need a reference. Done > s10.3.2.2: Expand BFD on (only) occurrence. May need a reference. Done > s10.4.1: Expand CDP on firat occurrence. Done > s10.4.2: Expand mDNS and DNS-SD on first occurrence. Done > 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.). Done We had long discussions about appendices and Michael Richardson made the IMHO excellent observation that nobody reads appendices given the RFC template thats pushing them all the way past all the text you wouldn't read like references, author addresses and the like. I would also claim that there are at leas three categories of information in section 10 that i would differentiate: 10.2/10.3 discuss as mentioned in before the operator interface. I can see how this can not be normative due to the absence of formal specification to achieve exact consistency. Thats the work that would need to go into a YANG model doc. But the operator interface is functionally a MUST HAVE OR ELSE YOUR IMPLEMENTATION IS UNDEPLOYABLE, so that makes it IMHO totally inappropriate for an appendix. 10.5 is similar but more controversal, so not clear to me if we would get to some easy agreement on the config model proposed here. The rest is either background or future considerations. So... afer i commit -14, i will commit a -15 where i will split 10. into a "Operational considerations" followed by a "Background and future considerations". I want to do this separately, because moving around subsections will make diffs totally useless. Then we can later have the discussion whether to move the background and future considerations into appendices. But i definitely do not want that for the operational considerations. > s12, paras 5 and 6: These are duplicates. Remove one! Done > s15.2: I think some of these references are normative: > especially ietf-anima-reference-model, ietf-roll-useofrplinfo, RFC 6553, > RFC 5234 Done except: See discussion on mailing list etc. we religiously do not want the reference model to be a normative reference, because it is really meant to only be a secondary document giving an overview of the ANI pieces (so the normative specs like BRSKI and GRASP are the normative references) AND then it talks about what we think a full AN network is, and that is totally incomplete and subject for further though. And not at all a dependency of ACP. Thank you so much!
- Re: [Gen-art] Gen-art LC Review of draft-ietf-ani… Toerless Eckert
- [Gen-art] Gen-art LC Review of draft-ietf-anima-a… Elwyn Davies
- Re: [Gen-art] Gen-art LC Review of draft-ietf-ani… Brian E Carpenter
- Re: [Gen-art] Gen-art LC Review of draft-ietf-ani… Toerless Eckert
- Re: [Gen-art] Gen-art LC Review of draft-ietf-ani… Elwyn Davies
- [Gen-art] Fwd: Re: Gen-art LC Review of draft-iet… Elwyn Davies
- Re: [Gen-art] Fwd: Re: Gen-art LC Review of? draf… Toerless Eckert
- Re: [Gen-art] Gen-art LC Review of? draft-ietf-an… Alissa Cooper
- Re: [Gen-art] [Anima] Gen-art LC Review of? draft… Brian E Carpenter
- Re: [Gen-art] [Anima] Gen-art LC Review of? draft… Toerless Eckert