[Rift] Re: Mike Bishop's Discuss on draft-ietf-rift-kv-tie-structure-and-processing-06: (with DISCUSS and COMMENT)

[Mike Bishop <[e-mail]>]

A few comments inline to clarify, but mostly looking forward to the updated draft version.

________________________________
From: Head, Jordan <[e-mail]>
Sent: Thursday, December 18, 2025 4:04 PM
To: Mike Bishop <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [Rift] Mike Bishop's Discuss on draft-ietf-rift-kv-tie-structure-and-processing-06: (with DISCUSS and COMMENT)

Hi Mike,

Thanks for the thorough review, replies inline as jhead>>

From: Mike Bishop via Datatracker <[e-mail]>
Date: Wednesday, December 17, 2025 at 11:44 AM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [Rift] Mike Bishop's Discuss on draft-ietf-rift-kv-tie-structure-and-processing-06: (with DISCUSS and COMMENT)

Mike Bishop has entered the following ballot position for
draft-ietf-rift-kv-tie-structure-and-processing-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!C2jc7wF2chOvOPajknCbmV1pw4nE8h7Byjda9op6nC7hGzq7vs8232akHUcOqVFYHVjYUr4MlgfgCg$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-rift-kv-tie-structure-and-processing/__;!!NEt6yMaO-gk!C2jc7wF2chOvOPajknCbmV1pw4nE8h7Byjda9op6nC7hGzq7vs8232akHUcOqVFYHVjYUr6XUQKJCw$



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

# IESG review of draft-ietf-rift-kv-tie-structure-and-processing-06

CC @MikeBishop

## Discuss

Several elements of this document did not make sense to me. I am far from an
expert in RIFT, and it may well be that some or all of these issues can be
fixed by my education rather than document changes.

### Section 2, paragraph 1
```
  2.  Key-Value Structure

     This section describes the generic key structure and semantics,
     Figure 1 further illustrates these components.
```
It is unclear from text whether this structure is being defined by this
document or referenced from RFC 9692. If referenced, please provide a more
specific pointer. If defined here, it probably doesn't go in the introduction.

      jhead>> A bit of both, I can clarify that the concept of the Keys and Values (i.e., KV TIEs) is defined normatively in RFC9692, but the structure within that is defined here.

[MB] I also see that this isn't in the Introduction and I read too quickly. Yes, please do explain the relationship between them — I'm looking at RFC 9692 and still not quite connecting the dots on what's new and what's pre-existing.

### Section 2.1, paragraph 9
```
           If the Key Sub-Type is used, it inherently reduces the Key
           Identifier space from 3-bytes to 2-bytes.  The Key Identifier
           SHOULD be unique within the context of the given Key Sub-Type.
           The Key Identifier is otherwise unchanged.

           The range of valid values is now 1 - 65535 (2^16-1).
```
How does a parser reconcile this with the previous statement that the Key
Identifier is 3 bytes long? This could be addressed by framing the Key Sub-Type
as a substructure of the (3-byte) Key Identifier, or alternatively by saying
that some Key Types fold the sub-type into the Identifier space.

      jhead>> It’s all governed by the Thrift IDL which both RFC9692 and this spec RECOMMENDS use of.
      jhead>> The normative Thrift model would be defined in the respective specification.

[MB] This gets into a related question of what's mandatory and what's guidance. If you RECOMMEND the use of a particular IDL (but others would also be compliant), then that IDL isn't your standard of conformance. If there's some other Thrift model that is normative, there needs to be a normative way to identify and reach that one.

### Section 2.4, paragraph 1

Needs a reference to the IEEE Registration Authority for OUIs (and
CIDs, presumably?).

      jhead>> Sure.

### Section 2.4, paragraph 1

Are OUI-36s supported, and if so, how? If not, please state that.

      jhead>> There is only 24 bits of space for the Identifier. I’d like to avoid stating what’s not supported as someone may choose to get creative later.

### Section 2.4, paragraph 2
```
     Type as OUI.  The Key Identifier MUST use the implementing
     organization's reserved OUI space to indicate the key and the
     semantics of any contained values.
```
How does one do that? I would have expected to find a three-byte OUI field,
followed by an OUI-scoped type sub-type field. If the "OUI Key Identifier" is
expected to contain the OUI, please state that (and then outline that OUI
owners will define their own sub-type fields as needed).

      jhead>> No Key Sub-Type for OUI for exactly the reason that it needs the 3-byte OUI for the Identifier.
      jhead>> I’ll clarify that the 3-byte OUI goes into the Key Identifier, good catch.

### Section 4, paragraph 2
```
     Per [RFC8126], IANA is requested to create two new registries in the
     "Routing in Fat Trees (RIFT)" registry group at
     https://urldefense.com/v3/__https://www.iana.org/assignments/rift__;!!NEt6yMaO-gk!C2jc7wF2chOvOPajknCbmV1pw4nE8h7Byjda9op6nC7hGzq7vs8232akHUcOqVFYHVjYUr5nAMfYIg$

     *  RIFT Key-Types
```
How is this different from the existing "RIFTCommonKVTypes Registry" established
by RFC 9692?

      jhead>> I’ll point the spec to that registry instead for Key Types.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

## Comments

### Section 2.3, paragraph 1
```
     This section reserves a value in the RIFT Key-Type Registry to
     indicate a Well-Known Key-Type.
```
Given that Key-Types are in a Specification Required registry, aren't they *all*
well-known? What differentiates a well-known key-type from any other type
defined in the future?

      jhead>> New Key Types are not specification required as defined in Section 7 of RFC9692 as they would not cause the RIFT schema to increment. If the RIFT schema increments, then it requires a new spec. In this case it’s expert review.
      jhead>> New Well-Known Key Sub-Types is also expert review per this spec.
      jhead>> The difference really comes down to whether or not a spec requires 2 bytes or 3 bytes of space. If they need 3 bytes then they’d use a new Key Type if 2 is enough then a new Well-Known Key Sub-Type would work.

[MB] Maybe some text could explain that this sets aside a way for types that don't need as much space to make a more conservative allocation?

### Section 2.3, paragraph 1
```
     Type as Well-Known.  The Well-Known Key-Type MUST support the use of
     a Key Sub-Type.  The Key Identifier will be used to identify the
```
No need for 2119 language here; there's no implementation requirement. Rather,
when this key type is used, the Sub-Type field is present and the Identifier
field is smaller..

### Section 3, paragraph 0
```
     *NOTE:*This document uses the terms to denote directionality,
     specifically, "northbound" meaning "toward the top of the fabric" and
     "southbound" meaning "toward the bottom of the fabric".
```
Consider moving this to a Terminology section in the Introduction.

      jhead>> I will restate to say “this section” as it’s the only portion of the doc that uses it. I’d rather leave it there so the context is better scoped.

## Nits

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://urldefense.com/v3/__https://github.com/larseggert/ietf-reviewtool__;!!NEt6yMaO-gk!C2jc7wF2chOvOPajknCbmV1pw4nE8h7Byjda9op6nC7hGzq7vs8232akHUcOqVFYHVjYUr5u7UjmWQ$ ), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 2.1, paragraph 8
```
-          Identifier space from 3-bytes to 2-bytes.  The Key Identifier
-                                 ^          ^
+          Identifier space from 3 bytes to 2 bytes.  The Key Identifier
+                                 ^          ^
```

      jhead>> Fixed.

#### Section 4, paragraph 1
```
-    Per [RFC8126], IANA is requested to create two new registries in the
-   ---------------
```

You don't need this reference unless you're normatively referencing
something in it.

      jhead>> Will adjust.

#### Section 6, paragraph 1
```
-    Thanks to Italo Busi for his very thoughtful review which yielded and
-                                                                        -
```

      jhead>> Fixed.

#### "Appendix A.", paragraph 1
```
-    This section contains the Thrift model that MAY be used to test
-                          ^^^
+    This section contains a Thrift model that MAY be used to test
+                          ^
```

      jhead>> Fixed.


_______________________________________________
RIFT mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]