Thank you ! On Thu, Aug 01, 2019 at 11:02:46AM -0700, Alissa Cooper via Datatracker wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-anima-autonomic-control-plane-20: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for addressing my DISCUSS. Original COMMENT is left below. > > General: > > Please address the Gen-ART reviewer's latest round of comments. > > There are a bunch of places in this document where it seems like there is a > tension between specifying a limited set of functionality here and being able > to support a wider variety of deployment scenarios. This is noted in Section 1 > but I think in general it would be clearer if uses of the term "future" > throughout the document could be more surgical as well as more specific about > whether they mean "people might deploy this differently in the future" or > "standards would need to be developed in the future." I've made a few > suggestions about some of these turns of phrase below but would suggest > someone > do a full edit pass with this in mind because there are a large number of > mentions of "future work." Of course there is always more work to do, but > every > bit of "future work" need not be mentioned in this document, and in cases > where > it is mentioned I think there should be a specific reason for doing so that > bears on people implementing this specification. I don't think this fits in > the > DISCUSS criteria but for a document that intends to be published on the > standards track I would expect it to be crisper about the dividing line > between > the normative behavior being specified here versus changes or extensions that > may or may not be made in the future. > > "Intent" is used both capitalized and in lower case throughout the document > and > I'm unclear if this is meant to signify a distinction or not. > > Section 2: > > Please remove the -->"..."() notation. > > Please use the exact boilerplate from RFC 8174, not a variation. > > It seems like RFC citations should appear for IKEv2 and DTLS upon first use in > this section. Otherwise, it seems they are first cited at different future > points in the document (Section 6.3 and 6.7, respectively). > > Section 3.3: > > "The ACP provides reachability that is independent of the Data-Plane > (except for the dependency discussed in Section 6.12.2 which can be > removed through future work)," > > Isn't this kind of a big exception, given that there is meant to be a secure > channel between pairs of nodes in the ACP and that developing future > encapsulations is non-trivial? It seems like phrasing this the other way > around > (the ACP is dependent on the Data-Plane for <XYZ> but is otherwise independent > of it) would be more accurate. > > Section 6: > > "Indestructible" seems like an overstatement. Maybe "resilient" would be more > accurate? > > Section 6.1.1: > > s/Such methods are subject to future work though./No such methods have been > defined at the time of publication of this document./ > > s/to build ACP channel/to build ACP channels/ > > s/that intends to be equally unique/that it intends to be equally unique/ > > ""rsub" is optional; its syntax is defined in this document, > but its semantics are for further study. Understanding the benefits > of using rsub may depend on the results of future work on enhancing > routing for the ACP." > > What is the point of defining this now when it is unclear if or how it will be > used? There are already means for nodes to do error handling, so it seems like > defining a new field in the future if/when it is needed would work fine and be > cleaner. Appendix A.7 seems to assume some semantics for this field, which > makes the way it is specified here even more confusing IMO. > > "In this specification, the "acp-address" field is REQUIRED, but > future variations (see Appendix A.8) may use local information to > derive the ACP address. In this case, "acp-address" could be empty. > Such a variation would be indicated by an appropriate "extension". > If "acp-address" is empty, and "rsub" is empty too, the "local-part" > will have the format "rfcSELF + + extension(s)". The two plus > characters are necessary so the node can unambiguously parse that > both "acp-address" and "rsub" are empty." > > This seems contradictory. Either "acp-address" is REQUIRED in which case there > are no exceptions, or it's not; if it's not, then the expected syntax for > cases > when it's not present should be specified. > > Section 6.1.2: > > s/If the node certificates indicates/If the node certificate indicates/ > > Section 6.3: > > It seems odd to provide a citation/discussion for IKEv2 here but not for DTLS. > > Section 6.4: > > This is a good example of a section where the blurring between the specified > behavior and expectations for the future is unhelpful IMO. Why specify the > current default and then spend a lot of words (including Appendix A.7) talking > about how it will be different in the future? > > Section 6.10.3.1: > > s/We do not think this is required at this point/This is not currently > required/ > > Section 6.12.2: > > s/may specify additional layer 2 or layer encapsulations/may specify > additional > layer 2 or layer 3 encapsulations/ (I think?) > > Section 8.2.1: > > This seems extraneous: "Future work could transform this into a YANG > ([RFC7950]) data > model." > > Appendix A.8: > > "Secure channels may > even be replaced by simple neighbor authentication to create > simplified ACP variations for environments where no real security is > required but just protection against non-malicious misconfiguration." > > I think experience has shown that even environments where it is assumed that > security is not required prove to need it. I would suggest removing this text > or changing this implication. > > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima
-- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
