IETF Last Call Review of draft-ietf-rift-kv-tie-structure-and-processing-05
review-ietf-rift-kv-tie-structure-and-processing-05-opsdir-lc-busi-2025-10-31-00

*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