Hi Chris, Thank you for your review and comments. I've uploaded version -27 and made changes as you suggested.
The possible downref to module 'INTF-EXT-YANG' and 'SUB-INTF-VLAN-YANG' as defined in https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/ is needed, and hopeful it will be published soon. Thanks, Yingzhen On Fri, Jan 8, 2021 at 1:38 PM Chris Bowers <[email protected]> wrote: > RTGWG and authors, > > There are a few items with respect to draft-ietf-rtgwg-policy-model > that need to be addressed before I produce the final version of the > Shepherd Writeup. > > http://www.ietf.org/tools/idnits/ applied to > draft-ietf-rtgwg-policy-model-26 > produces 1 warning and 4 comments. > > Yang Validation for draft-ietf-rtgwg-policy-model-26 on 2021-01-07 listed > one warning. > > Please address the following feedback on the text as well. > > Thanks, > Chris > > ========= > > Current title: > A YANG Data Model for Routing Policy Management > > Proposed title: > A YANG Data Model for Routing Policy > > ========= > Current abstract: > This document defines a YANG data model for configuring and managing > routing policies in a vendor-neutral way and based on actual > operational practice. The model provides a generic policy framework > which can be augmented with protocol-specific policy configuration. > > Proposed abstract: > 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. > > ========= > Section 1 > Current text: > The model is intended to be > vendor-neutral, in order to allow operators to manage policy > configuration in a consistent, intuitive way in heterogeneous > environments with routers supplied by multiple vendors. > > Proposed text: > The model is intended to be > vendor-neutral, in order to allow operators to manage policy > configuration in a consistent way in > environments with routers supplied by multiple vendors. > > ========== > Section 1.1 > Current text: > Despite the differences in details of policy expressions and > conventions in various vendor implementations, the model reflects the > observation that a relatively simple condition-action approach can be > readily mapped to several existing vendor implementations, and also > gives operators an intuitive and straightforward way to express > policy without sacrificing flexibility. A side effect of this design > decision is that legacy methods for expressing policies are not > considered. Such methods could be added as an augmentation to the > model if needed. > > Proposed text: > Despite the differences in details of policy expressions and > conventions in various vendor implementations, the model reflects the > observation that a relatively simple condition-action approach can be > readily mapped to several existing vendor implementations, and also > gives operators a familiar and straightforward way to express policy. > A side effect of this design decision is that other methods for expressing > policies are not considered. > > =========== > Section 4.1 > Current text: > o prefix sets - define a set of IP prefixes, each with an associated > IP prefix and netmask range (or exact length) > > o neighbor sets - define a set of neighboring nodes by their IP > addresses. These sets are used for selecting routes based on the > neighbors advertising the routes. > > o tag set - define a set of generic tag values that can be used in > matches for filtering routes > > Proposed text: > o prefix sets - Each prefix set defines a set of IP prefixes, each > with an associated > IP prefix and netmask range (or exact length). > > o neighbor sets - Each neighbor set defines a set of neighboring nodes > by their IP > addresses. A neighbor set is used for selecting routes based on the > neighbors advertising the routes. > > o tag sets - Each tag set defines a set of generic tag values that can > be used in > matches for filtering routes. > > ============ > Section 4.4 > Current text: > For example, some major implementations may only support a single level > of subroutine recursion. > > Proposed text: > For example, an implementation may only support a single level of > subroutine recursion. > > ============ > Section 9.1 > Current text: > Conditions may include multiple match > or comparison operations, and similarly actions may be a > multitude of changes to route attributes or a final > disposition of accepting or rejecting the route. > > Proposed text: > Conditions may include multiple match or comparison operations. > Actions may include changes to route attributes as well as a final > disposition of accepting or rejecting the route. > >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
