Hello, These are my technical comments on this draft, for the first 32 pages. Given the length of the document, I do not expect to be able to finish it by October 28, so I second Brian's request for additional time.
Bill 1) The definition of "ANI" in Section 2 says that it includes ACP, BRSKI and GRASP. The statement of Requirements in Section 4 says: "ACP4: The ACP MUST be generic. ... It MUST NOT be tied to a particular application or transport protocol." These two statements are in conflict, because the ANI as defined in this document clearly depends on GRASP. 2) As a specification, Step 4 in Section 5 is terrible. Step 3 explicitly includes the "for-loop". Step 4 then shifts to the perspective of an individual peer relationship, and uses the singular in the first sentence. It then shifts again to the plural for the second sentence. Suggested text: "4. For each node in the candidate peer list, it then establishes a secure tunnel of the negotiated type. The resulting tunnels are then placed into the previously set up VRF. This creates an overlay network with hop-by-hop tunnels." 3) In Section 6.1.1, in the comment on "routing-subdomain", it says, <<"rsub" is optional and should only be used when its impacts are understood.>> Who must do the understanding? What is the test for "understanding"? Is this a statement that "rsub" should not be used until the WG has done more work, or until the reader has read this document 42 times, or ?? For a normative section of this document, this is remarkably ambiguous. 4) In Section 6.2.3, para 1, line 3, "must" -> "MUST" (I believe that this requirement should be normative.) 5) In Section 6.7.2, para 2, line 4, "and not permit" -> "and MUST NOT permit" (The implied dependence on the previous "MUST" should be made explicit.) 6) In Section 6.8.2, para 2, I was puzzled by the statement that the ACP could exist in the absence of any active ACP neighbors, since the ACP is only created with the help of a neighbor that is already a member of the domain. I then realized that domain membership (and its accompanying domain certificate) could be established while a neighbor was active, and then the neighbor could vanish. I suggest adding some text to make this sequence of events clear. Suggestion: "It is created when the node has a domain certificate, and continues to exist even if all of its neighbors cease operation." On 15/10/2017 4:59 AM, Sheng Jiang wrote: > Hi all, > > > > This message starts the two-week ANIMA Working Group Last Call to > advance draft-ietf-anima-autonomic-control-plane-12, An Autonomic > Control Plane (ACP). This document's intended status is Standards Track. > At present, there is one IPR file against this document, see below link. > > > > https://datatracker.ietf.org/ipr/2407/ > > > > Please send your comments by October 28th, 2017. If you do not feel > this document should advance, please state your reasons why. > > > > Sheng JIANG is the assigned document shepherd. > > > > Regards, > > > > Sheng (co-chair, Toerless who as a co-author stayed neutral on the > content side) > > > > > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:[email protected] 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
