*Summary*

The document has issues and nits that should be resolved before publication.

*Issues*

Note that I am not a subject expert: if some of these comments can be addressed by reading some specific documents, it would be worthwhile adding some explicit pointers (better indicating also the sections, in addition to the documents).

1) Section 2

If I understand correctly the Key Identifier is unique within Key-Type.
If so, I would mention this explicitly.

2) Section 2

The document says that the Values field "SHOULD contain 1 or more elements"

Is your intention to preclude using the KV TIEs to carry empty Values?
If so, why it is a SHOULD and not a MUST? What happens if the Values is empty?

3) Section 2

What happens if the Values field length is not an integer multiplier of 4 bytes (e.g., 2 bytes)?
It will be just 2 bytes long or padded to become 4 bytes long?
I think this should be explicitly defined

4) Section 2.1

If I understand correctly, in this case, the Key Sub-Type is unique within Key-Type and the Key Identifier MUST be unique Key Sub-Type
If so, I would mention this explicitly.

5) Section 2.1

The document says that the Key Sub-Type MUST be used when the Key-Type is either Well-Known or Experimental.

As a consequence, it cannot be used for other Key-Type to be defined in future.
Is this the intention?
I am wondering whether the real intent was intention to say that whether the Key Sub-Type MUST be used or MUST NOT be used is defined by the Key-Type?
If this is the case, I would rephrase the sentence.

6) Section 2.1

I am not sure the requirement OPTIONAL should be capitalized.
If I understand correctly, the defining the Key Sub-Type is optional for the designer of the Key-Type and not optional to be implemented.
If the specific Key-Type (e.g., the Well Known Key-Type) defines the Key Sub-Type, the Key Sub-Type MUST be implemented.
If the specific Key-Type (e.g., the OUI Key-Type) does not defined the Key Sub-Type, the Key Sub-Type MUST NOT be implemented.

7) Section 2.3

The document requires that all the  "implementations SHOULD support" the Well-Known Key-Types

I am not sure we can RECOMMEND all the implementations to support all the values, especially sine some of these values can defined in future.
IMHO, the compliancy requirements for the Well-Known Key-Types should be defined in the RFC that defines the specific Well-Known Key-Type and not here.

Proposed rephrasing: "This section reserves a value in the RIFT Key-Type Registry to indicate a Well-Known Key-Type."

8) Section 3

The document says that "Key-Value elements SHOULD NOT be used to carry topology information used by RIFT itself to perform distributed computations."

Why it is a SHOULD and not a MUST? What happens if a Key-Value element is used to carry topology information?

9) Section 3.1.1

How to understand the format of the Values field (i.e., which bytes in the Values field carry the System ID and which bytes carry the Level)?
Maybe it is sufficient to provide a reference where the format and length for System ID and Level fields are defined.

10) Section 3.2 

This section defines the Key Targets and their processing and the Key Targets can be present on KV TIEs
However, it is not clear where and how the Key Targets can be present in the KV TIE format

11) Section 4.2.1

I am not sure we can allocate values with a Description and Reference "To be defined"

Either remove these values from the registry (Expert Review can be requested at a later stage) or add the Description and Reference\

12) Section 4.3

I think that the specification for a new RIFT Well-Known Key Sub-Type should not only provide the required fields but also how the Values field of the KV TIE is formatted to carry these fields (see my comment 9 above)
It is worthwhile mentioning this explicitly

13) Section 4.3

I think that the specification for a new RIFT Key-Type should also defined how the Key Identifier are assigned and, depending on whether Key Sub-Type can be used in future RIFT Key-Types (see comment 5 above), also whether the Key Sub-Type is defined or not for that Key-Type.
Please consider also the option to add a flag in Section 4.1.1 to track within the IANA Registry whether the Key Sub-Type is defined or not for that Key-Type.

*Nits*

13) Title

Please expand the acronyms in the I-D title: Routing in Fat Trees (RIFT) Key/Value Topology Information Elements

14) Abstract and Introduction

If I understand correctly, the RIFT protocols allows to advertise information using KV TIEs but it does not define the format of KV TIEs.
If so, it might be worthwhile mentioning this explicitly in the Abstract and Introduction.

15) Abstract and Introduction

In section 3, this document is also defining one Well-Known KT TIE for tie-breaking
It might be worthwhile mentioning this explicitly in the Abstract and Introduction

17) Figure 6

In Figure 4, the Key-Type allocated value 2 is explicitly shown.
I would align the style and shown explicitly the value 2 for the Key-Type and the value 127 for the Key Sub-Type fields.

18) Section 4:

I think that the name of second registry should be "RIFT Well-Known Key Sub-Types", as correctly used in the title of section 4.2

Regards, Italo