Document Shepherd feedback on draft-ietf-rtgwg-policy-model

[Chris Bowers <[e-mail]>]

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.