Reviewer: Mahesh Jethanandani
Review result: Almost Ready
This review is looking at the draft from a YANG perspective. With that said, I
have marked it as almost ready, because of some of the points discussed below.
Summary:
This document defines a YANG data model for configuring and managing routing
policies in a vendor-neutral way. The model provides a generic routing policy
framework which can be extended for specific routing protocols using the YANG
'augment' mechanism.
The description in the document and in the model is well written and easy to
understand.
Nits
- Repeat of parent as a prefix. It is not necessary to repeat the parent name
in child attributes, e.g. routing-policy -> policy-definitions ->
policy-definition. This can be shortened to routing-policy -> definitions >
definition.
s/domian/domain/
s/suspectable/susceptible/
- Consistency in how the reference statements are written. Most of the
reference statements start on a new line, except for a few places where they do
not.
Comments:
Section 1 - Introduction:
The document does not mention whether the model is YANG a 1.1 model. It
includes RFC 7950 which would imply a 1.1 module, and the YANG model has a
yang-version is 1.1., but it would be nice to state it explicitly.
Section 7.2
- Consider moving identity 'metric-type' and 'route-level' and their derived
identities into an IANA maintained module, e.g. 'iana-policy-types', so that
module can be updated separately from the rest of the module (much more easily).
- The leaf 'mode' is defined as an enumeration with enum values of ipv4 and
ipv6. The description however says:
"Indicates the mode of the prefix set, in terms of
which address families (IPv4, IPv6, or both) are
present."
How does a user indicate both?
The model uses a lot of groupings, most of them used only once in the model. It
does identify that prefix sets, neighbor sets and tag sets as reusable
groupings. Is that the case for the rest of the groupings? Unless these
groupings are meant for use by other models, they should be folded into the
main container.
Please drop <mailto:....> and just keep the e-mail address. That tag works only
when embedded within a HTML document. (This is a leftover item from the early
review, and if there was a discussion about it already, just ignore it).
Section 8 - Security Considerations:
The security considerations section lists /routing-policy as one of the nodes
as being sensitive from a write operation perspective. That would imply the
whole module is sensitive. It however, goes onto identifying specific nodes
within the module. Not clear if the whole module was intended to be identified
or specific nodes.
Similarly a sub-tree of the module is identified in
/routing-policy/policy-definitions.
If the idea of having a node without a description is to identify
(sub-)sections of the module where the nodes occur (the path already indicates
so), some words to that effect might help. E.g. In the
/routing-policy/policy-definitions section of the module the following nodes
are considered vulnerable.
The last paragraph is a fairly generic, and seems to repeat what is already
identified above. Moreover, it is not clear what is meant by "related model
carries potential risk". What is "related model"?
General
A pyang compilation of the model with —ietf and —lint option was clean. A
validation of the model and the example in Appendix B also succeeded. Thank you
for providing an example.
An idnits run of the draft was generally clean.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
