Summary: Has enough positions to pass.
Thank you for the SECDIR review from Valery Smyslov. Please review and respond to the remaining items. In particular, I concur with the recommendations about precise language around the names of the parameters. Section 3.1. babel-implementation-version. Is there any guidance on the format of this string (or is it free form like a Server: in HTTP)? Section 3.1. babel-metric-comp-algorithms, babel-mac-algorithms, babel-dtls-cert-types. Is there any guidance to provide on the delimiter between a list of values, or is that explicitly a data model issue? Section 3.1. babel-security-supported, babel-mac-algorithms, babel-dtls-cert-types. Consider providing citations on “MAC” and “DTLS”; and “HMAC-SHA256” and “BLAKE2s”; and “X.509” and “RawPublicKey” (just like was done for babel-metric-comp-algorithms). Section 3.8. babel-mac-key-value. If the algorithm is based on the HMAC construction [RFC2104], the length MUST be between 0 and the block size of the underlying hash inclusive (where "HMAC-SHA256" block size is 64 bytes as described in [RFC4868]). If the algorithm is "BLAKE2s", the length MUST be between 0 and 32 bytes inclusive, as described in [RFC7693]. I was under the impression that this was an information model to encode generic Babel protocol parameter and that the underlying protocol documents fully specified the normative behavior. However, this guidance appears to be introducing more restrictive configuration guidance not found in draft-ietf-babel-hmac making this document an information model + profile. Was this intentional? Section 3.8 and 3.9. babel-mac-key-test and babel-cert-test. It would be useful to explain the use case for this testing API. Section 5. Note that operations are also exposed in the information model. OLD This document defines a set of information model objects and parameters that may be exposed to be visible from other devices NEW This document defines a set of information model objects, parameters, and operations that may be exposed to be visible from other devices Section 5. Per: MAC keys are allowed to be as short as zero-length. This is useful for testing. Network operators are advised to follow current best practices for key length and generation of keys related to the MAC algorithm associated with the key. Short (and zero-length) keys and keys that make use of only alphanumeric characters are highly susceptible to brute force attacks. Add clarifying text that the information model explicitly enables this brute force attack where most of the workload is pushed onto the server (since it computes the hash). Also add a mitigation. Perhaps something like “This information model provides an oracle via the babel-mac-key-test operation that would enable such a brute force attack. Operators SHOULD rate limit access to this operation.”
Thanks for the updates in the -12 The following point was previously a discuss-level point, and I would still very much like to see textual changes to the document to either remove the restriction or justify it, but since it in practice seems like it will not impose an artificial limitation on achievable security I will drop to "no objection" for expediency: The current text limits the length of HMAC keys to be between 0 and the block length of the underlying hash function (e.g., 64 bytes for SHA-256). This limitation was previously present in the draft that became RFC 8967 but was removed in draft-ietf-babel-hmac-10. I do not know of a security or usability reason that justifies this restriction, and feel that having the information model diverge from the protocol spec requires some justification.
[[ nits ]] [ section 3.1 ] * s/running and operational/running any operational/?
The shepherd writeup is more than a year old. I wonder if we should get into the habit of asking that these be refreshed before they're scheduled on telechats. Please fix the boilerplate text from BCP 14 (your Section 1.1). Lastly, +1 to Barry's comments.
Just a couple of minor comments here: — Section 1.1 — Please use the exact BCP 14 boilerplate from RFC 8174. — Section 1.2 — For “datetime”, I suggest adding “Section 5.6” to the reference to RFC 3339, to make the specific format easier to find. And I think the use of 3339 in the definition of the type makes it a normative reference. Similarly, the use of ISO.10646 to define “string” makes it normative.
I want to revisit the question about including support for source-specific routing in the Information model. This topic came up already, but the discussion focused only on whether source-specific routing needed to be enabled or not, with one implementor mentioning that their implementation required it . In addition to enabling the functionality, and because "most of the information model is focused on reporting Babel protocol operational state" (§1), I am interested in the reporting side. It seems to me that the incremental cost to add this support is trivial (as described in §3/draft-ietf-babel-source-specific: "Data Structures"). Why is source-specific routing not supported? I find it to be a significant omission, especially considering that the source-specific routing spec is in IESG Evaluation at the same time.  https://mailarchive.ietf.org/arch/msg/babel/F7tlCQk8IeTaHN_rKHbsoKF3urE/
Thank you for the work put into this document. Please find below some non-blocking COMMENT points, and some nits. I also second Alvaro's question about the source-routing component. I hope that this helps to improve the document, Regards, -éric == COMMENTS == I have a slight concern that draft-ietf-babel-yang-model is not reviewed at the same time as the information model but, at least, they will be reviewed in the right order ;-) -- Section 3 -- For an informational document, I wonder whether the use of normative "MAY" is required. -- Section 3.2 -- About the UDP port, should the Babel default be part of the information model description ? I would prefer to leave it to the protocol specifications. Same remark applies to other objects/properties when the Babel default value is repeated in the information model. What is the usefulness of repeating it ? == NITS == -- Section 2 -- It is probably a matter of taste ;-) but I do not like too much the fact that all the objects names start with "babel-" as it is implicit.
Thank you for this document. I support Ben's discuss regarding reusing the terminology from NMDA. I think that the document should have a normative reference to RFC 8342, and probably explain that in some places the information model is using the same concepts of configuration and operational data separation described in NMDA. I also support Alvaro's question about whether the source-routing component should be included. This is just a comment, and I'm not proposing that you change tack, but I have to confess that I question how beneficial publishing an Information Model really is. I understand that the goal here is to be able to publish two different data models, one based on YANG and other based on BBF's [TR-181]. But what we end up with is an information model defined in a custom ad hoc language, which will naturally necessitate for the YANG and TR-181 models to be generated by hand, and for all three models to be kept up to date and consistent with each other. Hence, I wonder whether retrospectively it would have been better to just define the YANG model in IETF and ask BBF to use that as source reference to construct the TR-181 model from, ideally as a programmatic conversion, or failing that by hand. At least that way there are only two things to keep in sync rather than three. Regards, Rob