A YANG Data Model for Routing Policy
draft-ietf-rtgwg-policy-model-31

[Ballot comment]
I don't think you need the BCP 14 boilerplate in the prose part of this document.  You have exactly one of its keywords, at the bottom of Section 4.4, and you could find a way to say that normatively without bringing in BCP 14.  Your choice, of course.

[Ballot comment]
Thank you for the work put into this document. I really admire the 4 authors managing to reach a consensus even while having different affiliations: IETF at its best!

Please find below some non-blocking COMMENT points (but replies would be appreciated).


I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 2 --
Having "Policy chain: A policy chain is a sequence of policy definitions (described in Section 4)." in the terminology section does not really help the reader...

-- Section 4.1 --
While I am not a YANG expert, I wonder about the "*" (usually meaning 0 or more) for address in the neighbor-set container ? How can a neighbor exist w/o an address ? Why not using the "min-elements' YANG statement ?

[Ballot comment]
Thanks to Dan Harkins for the SECDIR review.

** Section 5.

  If none of the policy statement conditions
  are satisfied, then evaluation of the current policy definition
  stops, and the next policy definition in the chain is evaluated.

Is it worth mentioning in this paragraph that various implementation specific optimizations may be possible.  For example, Section 4.2 notes policy match conditions.  If the match condition is ALL and the first condition is not satisfied, is it necessary to evaluate the next policy statement?

** Section 8.  The text helpful notes the read sensitivity of “/routing-policy/policy-definitions/policy-definition” with “Additionally,      policies and their attendant conditions and actions should be considered proprietary and disclosure could be used to ascertain partners, customers, and supplies.”  It seems like “defined-sets/prefix-sets” could also reveal these relationships with partners, customers or suppliers.

[Ballot comment]
Section 4.2

  Comparison conditions may similarly use options to change how route
  attributes should be tested, e.g., for equality or inequality,
  against a given value.

I'm not sure if this is stale text, or if still current, which
operations it refers to (e.g., where is an "inequality" option
offered?).  Perhaps it is referring to the potential behavior of future
augmentations?

Section 4.4

  Note that the called policy may itself call other policies (subject
  to implementation limitations).  The model does not prescribe a
  nesting depth because this varies among implementations.  For
  example, an implementation may only support a single level of
  subroutine recursion.  [...]

Is there a useful way to programmatically determine the nesting limit of
a given implementation, or is this more of just a "read the
documentation" thing?

Section 5

  Whether or not the route's pre-policy attributes are used for testing
  policy statement conditions is dependent on the implementation
  specific value of the match-modified-attributes leaf.  If match-
  modified-attributes is false and actions modify route attributes,
  these modifications are not used for policy statement conditions.
  Conversely, if match-modified-attributes is true and actions modify
  the policy application-specific attributes, the attributes as
  modified by the policy are used for policy condition statements.

Are these "actions" in question only for the current policy statement,
all policy statements in the current policy definition, or all policy
definitions?  (I see on second read that this is an "ro" node at
effectively global scope, and so likely to be at the broadest "all
policy statements" scope, but I would still welcome some clarification.

Section 7.2

      enum  add-metric {
        description
          "Add the specified value to the existing metric.
          If the result would overflow the maximum metric
          (0xffffffff), set the metric to the maximum.";
      }

Is the parenthetical always fully generic?  I seem to recall that, e.g.,
the Babel YANG model uses a 16-bit field for the metric.

    container apply-policy {

It slightly surprised me that the import-policy and export-policy lists
both required an instance, but I am rather distanced from what is
actually done in practice, and it doesn't seem too hard to put in a
"reject everything" policy if needed.  OTOH, there are *also* separate
default-{import,export} policy leaves, that do have a default reject, so
the need to explicitly set at least one policy in both direction may be
overkill.

          leaf-list tag-value {
            type tag-type;
            description
              "Value of the tag set member.";

The tag-type is a union of uint32 and hex-string; does the notion of
"equivalence" for matching tags do any type conversion between those?
If not, a warning that the value set here must be of the correct type to
match the received (or generated?) route might be in order.

              container match-interface {
                leaf interface {
                  type leafref {
                    path "/if:interfaces/if:interface/if:name";

Is it always the case that the interface over which we receive a route
and the interface that traffic on that route is sent will be the same?
Or do we have to worry about potential skew between the two ways that
the interface comes into play?

              container match-neighbor-set {

I don't understand why there's no "match-set-options" analogue for
match-neighbor set.  Does the neighbor set use "ANY" matching semantics,
then?

              leaf set-route-preference {
                type uint16;
                description
                  "Set the preference for the route. It is also
                  known as 'administrative distance', allows for
                  selecting the preferred route among routes with
                  the same destination prefix. A smaller value is
                  more preferred.";

Thank you for including the last sentence!

Section 8

We should probably mention the apply-policy grouping as being
security-relevant (and how).

Section 11.1

Since RFCs 6241 and 8040 are only referenced from the security
considerations boilerplate (as examples of how YANG modules can be
used), they may not need to be classified as normative.

Appendix A,B

I didn't do much of a review here, since I'd need to understand
draft-ietf-idr-bgp-model in order to have very much useful to say, and
any such comments would accordingly be better directed at that draft.

NITS

Section 4.4

As an editorial matter, I'd consider adding a statement along the lines
of "when call-policy elements are present, a given policy statement
matches if all called policies return accept-route and all the other
conditions in the policy statement also match".  There don't seem to be
any other ways to read the current text that are reasonable, but it took
me a bit of thinking to work it out.

Section 7.2

  identity isis-level-1-2 {
    base route-level;
    description
      "Identity for IS-IS Level 1 and Level 2 area importation. It
      is only applicable to routes imported into the IS-IS
      protocol.";

The "importation into both" phrasing from ospf-normal-nssa reads much
more clearly to me than what's here.

          container prefixes {
            description
              "Container for the list of prefixes in a policy
              prefix list. Since individual prefixes do not have
              unique actions, the order in which the prefix in
              prefix-list are matched has no impact on the outcome
              and is left to the implementation. A given prefix-set
              condition is satisfied if the input prefix matches
              any of the prefixes in the prefix-set.";

The last sentence seems like it could be removed, since the
match-set-options leaf is what actually specifies the matching behavior
(and is not always "any").

              leaf set-application-tag {
                type tag-type;
                description
                  "Set the application tag for the route.
                  The application-specific tag is an additional tag
                  that can be used by applications that require
                  semantics and/or policy different from that of the
                  tag. For example, the tag is usually automatically
                  advertised in OSPF AS-External Link State
                  Advertisements (LSAs) while this application-specific
                  tag is not advertised implicitly.";

This seems to make more sense if I apply s/implicitly/explicitly/.

Section 8

      /routing-policy/defined-sets/prefix-sets -- Knowledge of these
      data nodes can be used to ascertain which local prefixes are
      susceptible to a Denial-of-Service (DoS) attack.

      /routing-policy/defined-sets/prefix-sets -- Knowledge of these
      data nodes can be used to ascertain local neighbors against whom
      to mount a Denial-of-Service (DoS) attack.

The second one reads like it should be "neighbor-set" rather than
"prefix-sets".

      /routing-policy/policy-definitions/policy-definition /statements/

Spurious space.

[Ballot comment]
No reference entries found for: [draft-ietf-idr-bgp-model-09]

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

"Table of Contents", paragraph 2, nit:
>  manage policy configuration in a consistent way in environments with routers
>                              ^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "consistently" to avoid
wordiness.

Section 3. , paragraph 4, nit:
> ations, and similarly, actions may effect multiple changes to route attribut
>                                    ^^^^^^
Did you mean "affect" (have an effect upon)?

Section 4.2. , paragraph 10, nit:
>  a reject-route action returns false and the calling policy evaluation will
>                                    ^^^^
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

Section 4.3. , paragraph 4, nit:
> eating policies nested beyond a small number of levels (e.g., 2-3) is discou
>                              ^^^^^^^^^^^^^^^^^
Specify a number, remove phrase, use "a few", or use "some".

Section 4.3. , paragraph 4, nit:
> o ensure that there is no recursion amongst nested routing policies. 5. Polic
>                                    ^^^^^^^
Do not mix variants of the same word ("amongst" and "among") within a single
text.

Section 4.4. , paragraph 2, nit:
> n is specified for the chain). Whether or not the route's pre-policy attribut
>                                ^^^^^^^^^^^^^^
Consider shortening this phrase to just "Whether". It is correct though if you
mean "regardless of whether".

Section 7.2. , paragraph 31, nit:
> existing metric. If the result would overflow the maximum metric (0xffffffff
>                                ^^^^^^^^^^^^^^
Consider removing "would". (Usually, "would" does not occur in a conditional
clause, unless to make a request or give a polite order.).

Section 7.2. , paragraph 33, nit:
> he existing metric. If the result would be less than 0, set the metric to 0.
>                                  ^^^^^^^^
Consider removing "would". (Usually, "would" does not occur in a conditional
clause, unless to make a request or give a polite order.).

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard is the type of RFC being requested for this document.
This is the proper type of RFC for a YANG model and is consistent with
the type of RFC used to publish other YANG models. The title page header
shows the intended status as Standards Track.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical 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.

Working Group Summary:

Significant input from the WG was incorporated into the document, and
the final version has strong consensus in the WG.

Document Quality:

The document is of high quality. 

A Yangdoctor early review was done by Mahesh Jethanandani.  This review
raised a few issues that were addressed to satisfaction of the reviewer
up updates to the draft text.

An initial Routing Area Directorate review was done by John Scudder.  This review
raised several issues, all of which were addressed in updates to the
draft text. 

A second Routing Area Directorate review was done by Jonathan Hardwick,
and the issues raised in that review have been addressed in the draft text.

A General Area Review team and a Transport Area Review team review were
also done.

Personnel:

Document Shepherd: Chris Bowers
Responsible Area Director: Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document was thoroughly reviewed by the document shephard.  Some minor issues
were found and the feedback was shared on the RTGWG list.  These minor issues have been
addressed, so the Document Shepherd thinks the document is now ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The Document Shepherd has no concerns in this respect.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Beyond the Routing Area Directorate and Yangdoctor reviews described above, no further specialized
reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

It is worth noting that one of the authors of draft-ietf-rtgwg-policy-model (Jeff Tantsura)
is a co-chair of RTGWG.  Therefore, Jeff was not involved in the conducting the WGLC for this
document or judging consensus.  The WGLC for this document was handled by Chris Bowers,
who at the time of the WGLC was the other co-chair of RTGWG.  After the document left
RTGWG, Yingzhen Qu replaced Chris Bowers as co-chair of RTGWG.  Yingzhen Qu is also
a co-author of draft-ietf-rtgwg-policy-model.  Chris Bowers has remained the Document Shepherd.

During WGLC in September 2020, an objection was raised with respect to requesting publication of
draft-ietf-rtgwg-policy-model before work on draft-ietf-idr-bgp-model is completed.  The main concern
expressed was that changes in draft-ietf-idr-bgp-model (which uses the YANG 'augment' mechanism to extend
draft-ietf-rtgwg-policy-model) may require changes in draft-ietf-rtgwg-policy-model.  Text was added to
draft-ietf-rtgwg-policy-model to make it clear that examples in draft-ietf-rtgwg-policy-model involving
draft-ietf-idr-bgp-model are not normative.  It was determined that there was consensus that this
additional text addressed the outstanding concern, and that the WG would would move forward with
requesting publication of the document. It was also stated that if there are changes in
draft-ietf-idr-bgp-model that make it desirable to change the text of the example
in draft-ietf-rtgwg-policy-model before publication, then any changes in
draft-ietf-rtgwg-policy-model will be discussed within RTGWG.

For more detail, see emails on the RTGWG list at:
https://mailarchive.ietf.org/arch/msg/rtgwg/D-3LV1oYmA1NF2r7JKjI8P7FsfY/
and
https://mailarchive.ietf.org/arch/msg/rtgwg/JnVDmuQBozko6DZMMYjsGjwDSzs/

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have stated that they are not aware of any IPR relevant to this draft.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR has been disclosed that references this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? 

The WG consensus behind this document is reasonably strong.  It is likely that only a subset of WG participants
has the existing YANG expertise or the willingness to spend the time needed to develop enough YANG expertise
needed to thoroughly review YANG data models.  Nevertheless, I think that RTGWG is the right venue for
standardizing this particular YANG data model, and that it received enough attention from WG participants
with respect to both YANG aspects and routing policy aspects. 

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

draft-ietf-rtgwg-policy-model-26 produces 1 warning and 4 comments
that the authors have been asked to address.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

As described above, a Yangdoctor early review has been done.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There are no normative references that are not RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The publication of this document will not change the status of any
existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section of this document are consistent with the IANA considerations
sections of existing RFCs documenting YANG modules.  It is consistent with the text
of the document as well.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are no new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The YANG module has been checked he recommended YANG validation tool as described below.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Yang Validation for draft-ietf-rtgwg-policy-model-30 on 2021-07-30 listed no errors or warnings.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-rtgwg-policy-model-29. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a new namespace will be registered as follows:

ID: yang:ietf-routing-policy
URI: urn:ietf:params:xml:ns:yang:ietf-routing-policy
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request.  Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

a new YANG module will be registered as follows:

Name: ietf-routing-policy
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-routing-policy
Prefix: rt-pol
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-06-22):

From: The IESG
To: IETF-Announce
CC: Chris Bowers , aretana.ietf@gmail.com, chrisbowers.ietf@gmail.com, draft-ietf-rtgwg-policy-model@ietf.org, rtgwg-chairs@ietf.org, rtgwg@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A YANG Data Model for Routing Policy) to Proposed Standard


The IESG has received a request from the Routing Area Working Group WG
(rtgwg) to consider the following document: - 'A YANG Data Model for Routing
Policy'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-06-22. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-policy-model/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard is the type of RFC being requested for this document.
This is the proper type of RFC for a YANG model and is consistent with
the type of RFC used to publish other YANG models. The title page header
shows the intended status as Standards Track.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical 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.

Working Group Summary:

Significant input from the WG was incorporated into the document, and
the final version has strong consensus in the WG.

Document Quality:

The document is of high quality. 

A Yangdoctor early review was done by Mahesh Jethanandani.  This review
raised a few issues that were addressed to satisfaction of the reviewer
up updates to the draft text.

A Routing Area Directorate review was done by John Scudder.  This review
raised several issues, all of which were addressed in updates to the
draft text.

A General Area Review team and a Transport Area Review team review were
also done.

Personnel:

Document Shepherd: Chris Bowers
Responsible Area Director: Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document was thoroughly reviewed by the document shephard.  Some minor issues
were found and the feedback was shared on the RTGWG list.  These minor issues have been
addressed, so the Document Shepherd thinks the document is now ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The Document Shepherd has no concerns in this respect.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Beyond the Routing Area Directorate and Yangdoctor reviews described above, no further specialized
reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

It is worth noting that one of the authors of draft-ietf-rtgwg-policy-model (Jeff Tantsura)
is a co-chair of RTGWG.  Therefore, Jeff was not involved in the conducting the WGLC for this
document or judging consensus.  The WGLC for this document was handled by Chris Bowers,
the other co-chair of RTGWG, who is also the Document Shepherd.

During WGLC in September 2020, an objection was raised with respect to requesting publication of
draft-ietf-rtgwg-policy-model before work on draft-ietf-idr-bgp-model is completed.  The main concern
expressed was that changes in draft-ietf-idr-bgp-model (which uses the YANG 'augment' mechanism to extend
draft-ietf-rtgwg-policy-model) may require changes in draft-ietf-rtgwg-policy-model.  Text was added to
draft-ietf-rtgwg-policy-model to make it clear that examples in draft-ietf-rtgwg-policy-model involving
draft-ietf-idr-bgp-model are not normative.  It was determined that there was consensus that this
additional text addressed the outstanding concern, and that the WG would would move forward with
requesting publication of the document. It was also stated that if there are changes in
draft-ietf-idr-bgp-model that make it desirable to change the text of the example
in draft-ietf-rtgwg-policy-model before publication, then any changes in
draft-ietf-rtgwg-policy-model will be discussed within RTGWG.

For more detail, see emails on the RTGWG list at:
https://mailarchive.ietf.org/arch/msg/rtgwg/D-3LV1oYmA1NF2r7JKjI8P7FsfY/
and
https://mailarchive.ietf.org/arch/msg/rtgwg/JnVDmuQBozko6DZMMYjsGjwDSzs/

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have stated that they are not aware of any IPR relevant to this draft.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR has been disclosed that references this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? 

The WG consensus behind this document is reasonably strong.  It is likely that only a subset of WG participants
has the existing YANG expertise or the willingness to spend the time needed to develop enough YANG expertise
needed to thoroughly review YANG data models.  Nevertheless, I think that RTGWG is the right venue for
standardizing this particular YANG data model, and that it received enough attention from WG participants
with respect to both YANG aspects and routing policy aspects. 

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

draft-ietf-rtgwg-policy-model-26 produces 1 warning and 4 comments
that the authors have been asked to address.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

As described above, a Yangdoctor early review has been done.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There are two normative references that are not RFCs. Both draft-ietf-netmod-sub-intf-vlan-model and
draft-ietf-netmod-intf-ext-yang are in the state "Waiting for WG Chair Go-Ahead". 

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There will be no downward normative references, assuming that draft-ietf-netmod-sub-intf-vlan-model and
draft-ietf-netmod-intf-ext-yang advance.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The publication of this document will not change the status of any
existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section of this document are consistent with the IANA considerations
sections of existing RFCs documenting YANG modules.  It is consistent with the text
of the document as well.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are no new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The YANG module has been checked he recommended YANG validation tool as described below.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Yang Validation for draft-ietf-rtgwg-policy-model-26 on 2021-01-07 listed one warning.
The authors have been asked to address this warning.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard is the type of RFC being requested for this document.
This is the proper type of RFC for a YANG model and is consistent with
the type of RFC used to publish other YANG models. The title page header
shows the intended status as Standards Track.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical 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.

Working Group Summary:

Significant input from the WG was incorporated into the document, and
the final version has strong consensus in the WG.

Document Quality:

The document is of high quality. 

A Yangdoctor early review was done by Mahesh Jethanandani.  This review
raised a few issues that were addressed to satisfaction of the reviewer
up updates to the draft text.

A Routing Area Directorate review was done by John Scudder.  This review
raised several issues, all of which were addressed in updates to the
draft text.

A General Area Review team and a Transport Area Review team review were
also done.

Personnel:

Document Shepherd: Chris Bowers
Responsible Area Director: Martin Vigoureux

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document was thoroughly reviewed by the document shephard.  Some minor issues
were found and the feedback was shared on the RTGWG list.  These minor issues have been
addressed, so the Document Shepherd thinks the document is now ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The Document Shepherd has no concerns in this respect.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Beyond the Routing Area Directorate and Yangdoctor reviews described above, no further specialized
reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

It is worth noting that one of the authors of draft-ietf-rtgwg-policy-model (Jeff Tantsura)
is a co-chair of RTGWG.  Therefore, Jeff was not involved in the conducting the WGLC for this
document or judging consensus.  The WGLC for this document was handled by Chris Bowers,
the other co-chair of RTGWG, who is also the Document Shepherd.

During WGLC in September 2020, an objection was raised with respect to requesting publication of
draft-ietf-rtgwg-policy-model before work on draft-ietf-idr-bgp-model is completed.  The main concern
expressed was that changes in draft-ietf-idr-bgp-model (which uses the YANG 'augment' mechanism to extend
draft-ietf-rtgwg-policy-model) may require changes in draft-ietf-rtgwg-policy-model.  Text was added to
draft-ietf-rtgwg-policy-model to make it clear that examples in draft-ietf-rtgwg-policy-model involving
draft-ietf-idr-bgp-model are not normative.  It was determined that there was consensus that this
additional text addressed the outstanding concern, and that the WG would would move forward with
requesting publication of the document. It was also stated that if there are changes in
draft-ietf-idr-bgp-model that make it desirable to change the text of the example
in draft-ietf-rtgwg-policy-model before publication, then any changes in
draft-ietf-rtgwg-policy-model will be discussed within RTGWG.

For more detail, see emails on the RTGWG list at:
https://mailarchive.ietf.org/arch/msg/rtgwg/D-3LV1oYmA1NF2r7JKjI8P7FsfY/
and
https://mailarchive.ietf.org/arch/msg/rtgwg/JnVDmuQBozko6DZMMYjsGjwDSzs/

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have stated that they are not aware of any IPR relevant to this draft.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR has been disclosed that references this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? 

The WG consensus behind this document is reasonably strong.  It is likely that only a subset of WG participants
has the existing YANG expertise or the willingness to spend the time needed to develop enough YANG expertise
needed to thoroughly review YANG data models.  Nevertheless, I think that RTGWG is the right venue for
standardizing this particular YANG data model, and that it received enough attention from WG participants
with respect to both YANG aspects and routing policy aspects. 

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

draft-ietf-rtgwg-policy-model-26 produces 1 warning and 4 comments
that the authors have been asked to address.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

As described above, a Yangdoctor early review has been done.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There are two normative references that are not RFCs. Both draft-ietf-netmod-sub-intf-vlan-model and
draft-ietf-netmod-intf-ext-yang are in the state "Waiting for WG Chair Go-Ahead". 

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There will be no downward normative references, assuming that draft-ietf-netmod-sub-intf-vlan-model and
draft-ietf-netmod-intf-ext-yang advance.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The publication of this document will not change the status of any
existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section of this document are consistent with the IANA considerations
sections of existing RFCs documenting YANG modules.  It is consistent with the text
of the document as well.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are no new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The YANG module has been checked he recommended YANG validation tool as described below.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Yang Validation for draft-ietf-rtgwg-policy-model-26 on 2021-01-07 listed one warning.
The authors have been asked to address this warning.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard is the type of RFC being requested for this document.
This is the proper type of RFC for a YANG model and is consistent with
the type of RFC used to publish other YANG models. The title page header
shows the intended status as Standards Track.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical 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.

Working Group Summary:

Significant input from the WG was incorporated into the document, and
the final version has strong consensus in the WG.

Document Quality:

The document is of high quality. 

A Yangdoctor early review was done by Mahesh Jethanandani.  This review
raised a few issues that were addressed to satisfaction of the reviewer
up updates to the draft text.

A Routing Area Directorate review was done by John Scudder.  This review
raised several issues, all of which were addressed in updates to the
draft text.

A General Area Review team and a Transport Area Review team review were
also done.

Personnel:

Document Shepherd: Chris Bowers
Responsible Area Director: Martin Vigoureux

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document was thoroughly reviewed by the document shephard.  Some minor issues
were found and the feedback was shared on the RTGWG list.  These minor issues have been
addressed, so the Document Shepherd thinks the document is now ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The Document Shepherd has no concerns in this respect.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Beyond the Routing Area Directorate and Yangdoctor reviews described above, no further specialized
reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

It is worth noting that one of the authors of draft-ietf-rtgwg-policy-model (Jeff Tantsura)
is a co-chair of RTGWG.  Therefore, Jeff was not involved in the conducting the WGLC for this
document or judging consensus.  The WGLC for this document was handled by Chris Bowers,
the other co-chair of RTGWG, who is also the Document Shepherd.

During WGLC in September 2020, an objection was raised with respect to requesting publication of
draft-ietf-rtgwg-policy-model before work on draft-ietf-idr-bgp-model is completed.  The main concern
expressed was that changes in draft-ietf-idr-bgp-model (which uses the YANG 'augment' mechanism to extend
draft-ietf-rtgwg-policy-model) may require changes in draft-ietf-rtgwg-policy-model.  Text was added to
draft-ietf-rtgwg-policy-model to make it clear that examples in draft-ietf-rtgwg-policy-model involving
draft-ietf-idr-bgp-model are not normative.  It was determined that there was consensus that this
additional text addressed the outstanding concern, and that the WG would would move forward with
requesting publication of the document. It was also stated that if there are changes in
draft-ietf-idr-bgp-model that make it desirable to change the text of the example
in draft-ietf-rtgwg-policy-model before publication, then any changes in
draft-ietf-rtgwg-policy-model will be discussed within RTGWG.

For more detail, see emails on the RTGWG list at:
https://mailarchive.ietf.org/arch/msg/rtgwg/D-3LV1oYmA1NF2r7JKjI8P7FsfY/
and
https://mailarchive.ietf.org/arch/msg/rtgwg/JnVDmuQBozko6DZMMYjsGjwDSzs/

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have stated that they are not aware of any IPR relevant to this draft.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR has been disclosed that references this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? 

The WG consensus behind this document is reasonably strong.  It is likely that only a subset of WG participants
has the existing YANG expertise or the willingness to spend the time needed to develop enough YANG expertise
needed to thoroughly review YANG data models.  Nevertheless, I think that RTGWG is the right venue for
standardizing this particular YANG data model, and that it received enough attention from WG participants
with respect to both YANG aspects and routing policy aspects. 

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

draft-ietf-rtgwg-policy-model-26 produces 1 warning and 4 comments
that the authors have been asked to address.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

As described above, a Yangdoctor early review has been done.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There are two normative references that are not RFCs. Both draft-ietf-netmod-sub-intf-vlan-model and
draft-ietf-netmod-intf-ext-yang are in the state "Waiting for WG Chair Go-Ahead". 

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There will be no downward normative references, assuming that draft-ietf-netmod-sub-intf-vlan-model and
draft-ietf-netmod-intf-ext-yang advance.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The publication of this document will not change the status of any
existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section of this document are consistent with the IANA considerations
sections of existing RFCs documenting YANG modules.  It is consistent with the text
of the document as well.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are no new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The YANG module has been checked he recommended YANG validation tool as described below.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Yang Validation for draft-ietf-rtgwg-policy-model-26 on 2021-01-07 listed one warning.
The authors have been asked to address this warning.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard is the type of RFC being requested for this document.
This is the proper type of RFC for a YANG model and is consistent with
the type of RFC used to publish other YANG models. The title page header
shows the intended status as Standards Track.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical 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.

Working Group Summary:

Significant input from the WG was incorporated into the document, and
the final version has strong consensus in the WG.

Document Quality:

The document is of high quality. 

A Yangdoctor early review was done by Mahesh Jethanandani.  This review
raised a few issues that were addressed to satisfaction of the reviewer
up updates to the draft text.

A Routing Area Directorate review was done by John Scudder.  This review
raised several issues, all of which were addressed in updates to the
draft text.

A General Area Review team and a Transport Area Review team review were
also done.

Personnel:

Document Shepherd: Chris Bowers
Responsible Area Director: Martin Vigoureux

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document was thoroughly reviewed by the document shephard.  Some minor issues
were found and the feedback has been shared on the RTGWG list.  The Document Shepherd
thinks the document will be ready for publication once these minor issues are addressed.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The Document Shepherd has no concerns in this respect.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Beyond the Routing Area Directorate and Yangdoctor reviews described above, no further specialized
reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

It is worth noting that one of the authors of draft-ietf-rtgwg-policy-model (Jeff Tantsura)
is a co-chair of RTGWG.  Therefore, Jeff was not involved in the conducting the WGLC for this
document or judging consensus.  The WGLC for this document was handled by Chris Bowers,
the other co-chair of RTGWG, who is also the Document Shepherd.

During WGLC in September 2020, an objection was raised with respect to requesting publication of
draft-ietf-rtgwg-policy-model before work on draft-ietf-idr-bgp-model is completed.  The main concern
expressed was that changes in draft-ietf-idr-bgp-model (which uses the YANG 'augment' mechanism to extend
draft-ietf-rtgwg-policy-model) may require changes in draft-ietf-rtgwg-policy-model.  Text was added to
draft-ietf-rtgwg-policy-model to make it clear that examples in draft-ietf-rtgwg-policy-model involving
draft-ietf-idr-bgp-model are not normative.  It was determined that there was consensus that this
additional text addressed the outstanding concern, and that the WG would would move forward with
requesting publication of the document. It was also stated that if there are changes in
draft-ietf-idr-bgp-model that make it desirable to change the text of the example
in draft-ietf-rtgwg-policy-model before publication, then any changes in
draft-ietf-rtgwg-policy-model will be discussed within RTGWG.

For more detail, see emails on the RTGWG list at:
https://mailarchive.ietf.org/arch/msg/rtgwg/D-3LV1oYmA1NF2r7JKjI8P7FsfY/
and
https://mailarchive.ietf.org/arch/msg/rtgwg/JnVDmuQBozko6DZMMYjsGjwDSzs/

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have stated that they are not aware of any IPR relevant to this draft.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR has been disclosed that references this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? 

The WG consensus behind this document is reasonably strong.  It is likely that only a subset of WG participants
has the existing YANG expertise or the willingness to spend the time needed to develop enough YANG expertise
needed to thoroughly review YANG data models.  Nevertheless, I think that RTGWG is the right venue for
standardizing this particular YANG data model, and that it received enough attention from WG participants
with respect to both YANG aspects and routing policy aspects. 

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

draft-ietf-rtgwg-policy-model-26 produces 1 warning and 4 comments
that the authors have been asked to address.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

As described above, a Yangdoctor early review has been done.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There are two normative references that are not RFCs. Both draft-ietf-netmod-sub-intf-vlan-model and
draft-ietf-netmod-intf-ext-yang are in the state "Waiting for WG Chair Go-Ahead". 

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There will be no downward normative references, assuming that draft-ietf-netmod-sub-intf-vlan-model and
draft-ietf-netmod-intf-ext-yang advance.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The publication of this document will not change the status of any
existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section of this document are consistent with the IANA considerations
sections of existing RFCs documenting YANG modules.  It is consistent with the text
of the document as well.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are no new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The YANG module has been checked he recommended YANG validation tool as described below.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Yang Validation for draft-ietf-rtgwg-policy-model-26 on 2021-01-07 listed one warning.
The authors have been asked to address this warning.