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

["Head, Jordan" <[e-mail]>]

Yes, now that I confirmed with you, I’ll push the draft momentarily.

From: Mike Bishop <[e-mail]>
Date: Tuesday, January 6, 2026 at 10:37 AM
To: Head, Jordan <[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)

Great, that should work. Are those changes going in an -08?
________________________________
From: Head, Jordan <[e-mail]>
Sent: Monday, January 5, 2026 1:56 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 continued follow up. Replies inline as jhead[3]>>

Jordan

From: Mike Bishop <[e-mail]>
Date: Wednesday, December 31, 2025 at 4:44 PM
To: Head, Jordan <[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)

The updated draft covers lots of this — thank you. Let me start by making sure I'm tracking properly first:


  *
RFC 9692 defines a generic KV-TIE structure with a three-byte Key Identifier and a variable-length Value.
  *
Semantics within this structure are largely undefined by RFC 9692. The interpretation of the Key Identifier depends on the Key Type; the interpretation of the Value depends on the Key Type (and likely the Key Identifier, presuming the Key Type's spec says it should).
  *
RFC 9692 defines some Key Types, but doesn't give any further guidance on the interpretation of their Key Identifier and Values.
  *
This document:
     *
Defines specific interpretation of the Key Identifier and Value for the Key Types defined in RFC 9692, and
     *
Defines an additional Key Type (Well-Known), along with Key Identifier/Value interpretation for it
        *
...by creating an additional layer of registration, and saying that Value is defined by the spec that registers a given Sub-Type and Sub-Identifier combination.

If that's correct, I think these are my outstanding issues/suggestions:

  *
Since this gives structure to something that was previously implementation-dependent in RFC 9692, is that an Update to 9692?

jhead[3]>> No update necessary. RFC9692 defines the flooding scope and SPF computation regardless of how the KVs are structured.


  *
How does an implementation determine that the structure in this document applies to the data it's receiving, versus the more "free-form" structure in 9692? That is, does there need to be some form of negotiation or signal that this structure applies?

jhead[3]>> RFC9692 defines the existence of a KV Tie “Type” (see TIETypeType in RFC9692 here<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9692.html*name-riftcommontietypetype-regis__;Iw!!NpxR!hu6Rw2DanrRn9p4XtkFSalAb6fQdl2WZWQ4BJidq4-xMyAIe-b87GYmp1PonfldE9gIGzwDrInl1HjChankG$>) That is to say, if an implementation is compliant, it can recognize a TIE as a Key Value TIE to handle necessary flooding, SPF, etc. This would be known prior to even attempting to parse the contents (keys and values) themselves.

jhead[3]>> After determining that a TIE is in fact a KV TIE, if what it received is a structure it does not understand, it floods it anyway. This is intentional as we know there are cases where some nodes may support a structure but other nodes do not. As such, no negotiation or signaling is required.


  *
In Section 2.1 and 2.2, there's no need for the 2119 language (MUST/OPTIONAL) for describing "support of" the Sub-Identifier. Rather, by definition, when Key Type is Well-Known or Experimental, the Key Identifier field has this additional structure.
  *
In Section 2.4, the situation is similar. Rather than "The Key Identifier MUST...", you can simply state that the semantics of the Value field (including any vendor-administered sub-typing) are defined by the vendor whose OUI is in the Key Identifier field.

jhead[3]>> Unless you think that leaving this in inherently reduces the document’s quality, I’d prefer to leave it in.


  *
Could you add a pointer to the definition/registration for OUIs?

jhead[3]>> Yes. I’ve added the same one we use in the base spec.


  *
I'd still like to see some text on when an application should use Well-Known. This doesn't need to be long at all; something as short as "Most applications don't need a dedicated space of 16.7M key identifier values, while the supply of Key Types is relatively limited. Well-Known allows applications that only require a few key identifiers to share a single Key Type with other small reservations."

jhead[3]>> Yeah, I was thinking about this over the holiday and I agree with you. I’ve added some text to the Design Considerations section.

________________________________
From: Head, Jordan <[e-mail]>
Sent: Tuesday, December 30, 2025 10:39 AM
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)

Thanks for the follow up, Mike. Replies inline as jhead[2]>>

Also, I’ve pushed the new spec.

From: Mike Bishop <[e-mail]>
Date: Monday, December 29, 2025 at 4:22 PM
To: Head, Jordan <[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)

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.

jhead[2]>> In short, RFC9692 defines KV TIE existence, some high level protocol behavior, etc. and provides the Thrift model to support the current Key Types (Well-Known, Experimental, OUI).
jhead[2]>> This spec​, describes how they are used and defines the new Key Sub-Type component.
jhead[2]>> I adjusted the language to clarify while trying to avoid over specification.

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

jhead[2]>> I added a bullet to the expert review guidance that basically says “if an implementation uses Thrift check if there is a normative thrift model”, but I can only specify so much (normatively) as neither RFC9692 nor this spec states that one MUST use Thrift.

### 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?

jhead[2]>> It’s more about an implementation truly considering all the possible/relevant variables that could impact their given use-case, several of them would vary on scale, topology, etc. While I do understand the desire to add guidance here, in this scenario it’s simply outside the scope for us to enumerate things an implementation “should” consider in a non-normative sense.

### 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]