Re: [Anima] Alissa Cooper's No Objection on draft-ietf-anima-autonomic-control-plane-20: (with COMMENT)

[Toerless Eckert <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[e-mail]