YANG Data Model for Routing in Fat Trees (RIFT)
draft-ietf-rift-yang-17

[Ballot comment]
The shepherd writeup says this document is seeking Internet Standard status, but the document itself and the datatracker metadata put it at Proposed Standard.  I presume the latter is correct.

It also says this isn't a protocol document, but why is it seeking Proposed Standard status if that's the case?  Are YANG documents normally something else?

Section 1.1 defines "ThreeWay" but everywhere else in the document it's "Three Way".

[Ballot comment]
Thanks to Michal Vasko for his YANG doctor's review.

Thanks to Jordon Head for the shepherd writeup. The writeup was done in 2022 though. I wonder if anything has changed in the interim. I will note that the document is a protocol document, and as such could do with an implementation.

Section 1.1, paragraph 4
>    The terminology for describing YANG data models is found in [RFC6020]
>    and [RFC7950], including:
>
>    *  augment
>
>    *  container
>
>    *  choice

This is a draft that defines YANG module. It is assumed that anyone who is reviewing a YANG model is familiar with these terms. It is therefore redundant to repeat them here. I would just remove them.

Section 2.1, paragraph 3
>    The RIFT YANG module augments the /routing/control-plane-protocols/
>    control-plane-protocol path defined in the ietf-routing module.  The
>    ietf-rift model defines a single instance of RIFT.  Multiple
>    instances are instantiated as multiple control-plane protocols
>    instances.

The last statement does not make sense. I think you mean to say "Multiple instances of the protocol are supported by the module by giving them unique names (as key)".  As a note, the routing module supports several control plane protocols, not several instances of them. This model augments the routing module to add RIFT as a control plane protocol. It then offers the ability to create a list of instances, which it does by declaring 'list rift'.

Section 2.2, paragraph 1
>    This model imports and augments ietf-routing YANG model defined in
>    [RFC8349].  Both configuration branch and state branch of [RFC8349]
>    are augmented.  The configuration branch covers node base and policy
>    configuration.  The container "rift" is the top level container in
>    this data model.  The container is expected to enable RIFT protocol
>    functionality.

RFC8349 does not have two separate configuration and state branches. Not if you were following the NMDA module, which is noted below in the document. Suggest removing the second and third sentences in the paragraph.

Section 2.3, paragraph 2
>    The RIFT YANG module augments the /routing/control-plane-protocols/
>    control-plane-protocol path defined in the ietf-routing module.  The
>    ietf-rift model defines a single instance of RIFT.  Multiple
>    instances are instantiated as multiple control-plane protocols
>    instances.

Same comment as above. Suggest rewording the last sentence to say, "Multiple instances of the protocol are supported by the module by giving each instance a unique name".

Section 2.3, paragraph 2
>    module: ietf-rift

Instead of displaying the entire tree diagram, it would help to break it into chunks and explain each section of the module as part of the overview of the model. For example, what is the 'database' section of the module (I think Eric had the same question)? Does each notification need to carry all the data defined under it, or could it do with a smaller set of data, and the rest requested using a  when more information is desired?

Section 2.3, paragraph 1
>          +--ro spf-statistics
>          |  +--ro spf-statistics* [spf-direction-type]
>          |    +--ro spf-direction-type    enumeration
>          |    +--ro start-time?          yang:date-and-time
>          |    +--ro end-time?            yang:date-and-time
>          |    +--ro triggering-tie
>          |        +--ro tie-direction-type?    enumeration
>          |        +--ro originator?            system-id
>          |        +--ro tie-type?              enumeration
>          |        +--ro tie-number?            uint32
>          |        +--ro seq?                    uint64
>          |        +--ro size?                  uint32
>          |        +--ro origination-time?      ieee802-1as-timestamp
>          |        +--ro origination-lifetime?  uint32
>          |        +--ro remaining-lifetime?    uint32


I would suggest that all statistics be combined in a single container called 'statistics'. Currently, they are scattered all over the module. That will enable a user to specify the container to get all stats, and it enables clearing stats when they are clubbed together in one container. Which remind me. There should be action to clear stats within a model. Finally, instead of using uint32, consider using zero-based-counter32.

Section 3, paragraph 22
>        Copyright (c) 2022 IETF Trust and the persons identified
>        as authors of the code.  All rights reserved.


The Copyright year needs to be updated.

Possible DOWNREF from this Standards Track doc to [IEEE8021AS]. If so, the IESG
needs to approve it.

Found IP blocks or addresses not inside RFC5737/RFC3849 example ranges:
"224.0.0.121" and "ff02::a1f7".

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

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.

"Authors' Addresses", paragraph 4

Section 1.1, paragraph 16
>    LIE: "Link Information Element" are exchanged on all the system's
>    links running RIFT to form _ThreeWay_ adjacencies and carry
>    information used to perform Zero Touch Provisioning (ZTP) of levels.

Why the _ before and after ThreeWay here and the other definitions? Is this different from ThreeWay Adjacency?

Section 2.1, paragraph 1
>    The model covers RIFT [I-D.ietf-rift-rift].

Seems like a redundant statement, as the next paragraph explains what the model is about.

Section 3, paragraph 98
>  } config false; description "The type of a link."; } description "The type o
>                                  ^^^^^^^^^
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

Section 3, paragraph 98
> he type of a link."; } description "The type of a link."; Zhang, et al. Expir
>                                        ^^^^^^^^^
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

Section 3, paragraph 105
> false; description "The direction type of a TIE."; } description "The directi
>                                  ^^^^^^^^^
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

Section 3, paragraph 105
> E."; } description "The direction type of a TIE."; } // tie-direction-type g
>                                  ^^^^^^^^^
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

Section 3, paragraph 106
>  2024 description "The direction type of a SPF calculation."; } description "
>                                  ^^^^^^^^^
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

Section 3, paragraph 106
> n."; } description "The direction type of a SPF calculation."; } // spf-direc
>                                  ^^^^^^^^^
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

Section 3, paragraph 140
> fault link capabilities. It can be overwrite by the configuration underneath
>                                ^^^^^^^^^^^^
There may an error in the verb form "be overwrite".

Section 3, paragraph 155
>  boolean; description "If this link allow horizontal link adjacency."; } con
>                                    ^^^^^
"link" is a singular noun. It appears that the verb form is incorrect.

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-rift-yang-16
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-rift-yang-16.txt&submitcheck=True

## Comments

### 2.4.  RIFT configuration

```
647   Some features can be used to enhance protocol, such as BFD [RFC5881],
648   flooding-reducing, community attribute.
```

The language in this section might be improved, and citations could be provided for "flooding-reducing", "community attribute".

## Nits

### Possibly normative should

```
657   Unexpected TIE and neighbor's layer error should be notified.
```

```
1717               This should be prohibited less than 2*purge-lifetime.";
```

I do not have enough context to understand if these are clear enough, or if they ought to be a normative SHOULDs.

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-rift-yang-16

Changed on 2Aug2024 from No Record to No Objection

Original AD concern:

When going through the document most of the items are included and realize that a great deal of work and detail went into the proposed model.
I do have one observation that confuses me and that is the relationship with the RIFT Thrift model used.

The RIFT specification has a Thrift data model embedded which is documented in section 7:
https://datatracker.ietf.org/doc/html/draft-ietf-rift-rift-24#section-7

It is unclear to me if the proposed YANG model aligns or has deviations of this Thrift model. Is the use case for both different?
Would it make sense to consider a table to align both models where appropriate? Have both models similar intent?

Answer from Bruno Rijsman:

* The use case and the intent for the Thrift model and the YANG model are quite different.
* The Thrift model describes the control-plane protocol, i.e. encoding of control-plane messages between routers.
* The YANG model describes the management-plane, i.e. the attributes that need to be configured / monitored by the network management system.
* They are already aligned in the sense that the YANG data model already describes what needs to be managed about the Thrift-described control plane protocol.

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-rift-yang-16

Currently i did not decide to ballot DISCUSS or No Objection

When going through the document most of the items are included and realize that a great deal of work and detail went into the proposed model.
I do have one observation that confuses me and that is the relationship with the RIFT Thrift model used.

The RIFT specification has a Thrift data model embedded which is documented in section 7:
https://datatracker.ietf.org/doc/html/draft-ietf-rift-rift-24#section-7

It is unclear to me if the proposed YANG model aligns or has deviations of this Thrift model. Is the use case for both different?
Would it make sense to consider a table to align both models where appropriate? Have both models similar intent?

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-rift-yang-15

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Jordan Head for the shepherd's concise write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric



# COMMENTS (non-blocking)

## Lack of 'basic' operating values

I was expecting to see some leaves about basic counters, i.e., number of RIFT packets sent and received per interface. The only counter in the YANG model appears to be "number-of-flaps", it this counter enough for operation ?

## Abstract

Suggest adding a reference to the rift draft (with a RFC editor note requesting to update it with the rift RFC when known). Or use "XXXX" per the section 5 note.

## Section 2.1

`The model contains all the basic configuration parameters to operate the protocol` unsure whether configuration alone is enough to operate a protocol... Suggest adding "status values" to "configuration parameters" and as a protocol cannot really be operated, use "to operate a RIFT network".

## Section 2.5

The title "state" seems to relate to the "database" YANG node. If I am reading it correctly, then please update the section title and text.

## Section 3

In several descriptions there is a reference to a section but it is (somehow) unclear in which document (as it is specified in the reference); suggest doing like "feature tie-security" for all features (i.e., section in the reference).

The default MTU in `leaf mtu-size` is 1400, which is rather unusual... It is often 1500 or 1280 (for IPv6 minimum link MTU). Is there any reason for this 1400 value ? If so, some explanations or reference will be welcome.


# NITS (non-blocking / cosmetic)

## PoD or POD

Sometimes "PoD" is used and other times "POD" is used. Suggest being consistent.

## Section 1.1

Sometimes `This is an acronym for` is used, and other times the acronym is directly defined.

## Section 3

Please use lowercase only in `default "FF02::A1F7";`

Suggest renaming  the `leaf ttl` into "leaf hop-limit"

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

IANA has completed its review of draft-ietf-rift-yang-11. If any part of this review is inaccurate, please let us know.

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

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

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

a single new namespace will be registered as follows:

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

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated and completed the required Expert Review via a separate request.

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

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

a single new YANG module will be registered as follows:

Name: ietf-rift
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-rift
Prefix: rift
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.

We understand 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.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-06-21):

From: The IESG
To: IETF-Announce
CC: draft-ietf-rift-yang@ietf.org, james.n.guichard@futurewei.com, jhead@juniper.net, rift-chairs@ietf.org, rift@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (YANG Data Model for Routing in Fat Trees (RIFT)) to Proposed Standard


The IESG has received a request from the Routing In Fat Trees WG (rift) to
consider the following document: - 'YANG Data Model for Routing in Fat Trees
(RIFT)'
  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 2024-06-21. 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 the configuration and
  management of Routing in Fat Trees (RIFT) Protocol.  The model is
  based on YANG 1.1 as defined in RFC7950 and conforms to the Network
  Management Datastore Architecture (NMDA) as described in RFC8342.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rift-yang/



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

# Document Shepherd Writeup
## Jordan Head
## June 7th, 2022

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup to give helpful context to Last Call and
Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in
completing it, is appreciated. The full role of the shepherd is further
described in [RFC 4858][2], and informally. You will need the cooperation of
authors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This documents consensus reached broad agreement from the working group.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversial discussions.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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 threads of appeal or extreme discontent were noted in WG discussions.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This is not a protocol document.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

All necessary reviews have taken place, nothing further is required.

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

YANG Doctors reviewed a previous version (-03) of this document as "Almost Ready".

Current version addresses all concerns mentioned in that review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

YANG validation was run with 0 warnings and 0 errors.

The YANG modules complies with the NMDA architecture per RFC8342.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document contains a YANG module and was successfully validated by datatracker's automatic YANG validation tool.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is certainly needed to programmatically describe RIFT's configuration and operational state.

There was active participation from the working group both in terms of comments and detailed review/editing to get the YANG module where it is now. This includes individuals from at least 2 separate implementations of the protocol being described (RIFT).

This document is complete, any and all concerns have been addressed, and is ready to move forward.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

I have no concerns with this document based on the Routing Area's list.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

This draft is intended to move forward as an Internet Standard and is correctly documented as such.

With multiple implementations of the protocol it describes (RIFT) it is the correct type of publication.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

No IPRs were disclosed for this document and all authors have stated this during last call.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

Yes.

This document has 5 authors, there is no need for more to be listed.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

- There is 1 instance of exceeding the character limit of 72 (by 2), but this is syntactically relevant to the YANG module contained in the draft.

- There are 3 instances of "weird spacing", but this is syntactically relevant to the YANG module contained in the draft.

- There is 1 instance of a "possible downref", but the is an IEEE standard that is both relevant to the document and freely available.

15. Should any informative references be normative or vice-versa?

No, all references are complete and correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All references are freely available.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

No.

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

No. The main RIFT specification is currently progressing through AD review.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No, this document does not change the status of any existing RFCs.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

The document makes multiple registry requests:

- A new URI from the IETF XML Registry (RFC3688/BCP81).
- A new YANG module name from the YANG Module Names Registry (RFC6020).

All IANA registry requests in the document are associated with the correct IANA registries and conform to their respective procedures.

All necessary IANA regristry's are correctly referenced in the "IANA Considerations" section.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new registries are being requested.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

# Document Shepherd Writeup
## Jordan Head
## June 7th, 2022

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup to give helpful context to Last Call and
Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in
completing it, is appreciated. The full role of the shepherd is further
described in [RFC 4858][2], and informally. You will need the cooperation of
authors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This documents consensus reached broad agreement from the working group.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversial discussions.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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 threads of appeal or extreme discontent were noted in WG discussions.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This is not a protocol document.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

All necessary reviews have taken place, nothing further is required.

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

YANG Doctors reviewed a previous version (-03) of this document as "Almost Ready".

Current version addresses all concerns mentioned in that review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

YANG validation was run with 0 warnings and 0 errors.

The YANG modules complies with the NMDA architecture per RFC8342.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document contains a YANG module and was successfully validated by datatracker's automatic YANG validation tool.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is certainly needed to programmatically describe RIFT's configuration and operational state.

There was active participation from the working group both in terms of comments and detailed review/editing to get the YANG module where it is now. This includes individuals from at least 2 separate implementations of the protocol being described (RIFT).

This document is complete, any and all concerns have been addressed, and is ready to move forward.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

I have no concerns with this document based on the Routing Area's list.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

This draft is intended to move forward as an Internet Standard and is correctly documented as such.

With multiple implementations of the protocol it describes (RIFT) it is the correct type of publication.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

No IPRs were disclosed for this document and all authors have stated this during last call.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

Yes.

This document has 5 authors, there is no need for more to be listed.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

- There is 1 instance of exceeding the character limit of 72 (by 2), but this is syntactically relevant to the YANG module contained in the draft.

- There are 3 instances of "weird spacing", but this is syntactically relevant to the YANG module contained in the draft.

- There is 1 instance of a "possible downref", but the is an IEEE standard that is both relevant to the document and freely available.

15. Should any informative references be normative or vice-versa?

No, all references are complete and correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All references are freely available.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

No.

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

No. The main RIFT specification is currently progressing through AD review.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No, this document does not change the status of any existing RFCs.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

The document makes multiple registry requests:

- A new URI from the IETF XML Registry (RFC3688/BCP81).
- A new YANG module name from the YANG Module Names Registry (RFC6020).

All IANA registry requests in the document are associated with the correct IANA registries and conform to their respective procedures.

All necessary IANA regristry's are correctly referenced in the "IANA Considerations" section.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new registries are being requested.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html