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

[Roman Danyliw <[e-mail]>]

Hi Jordan!

Thanks for the quick response.  Your proposed approach works for me and would resolve my feedback.

Roman

From: Head, Jordan <[e-mail]>
Sent: Tuesday, December 16, 2025 5:30 PM
To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Roman Danyliw's Discuss on draft-ietf-rift-kv-tie-structure-and-processing-06: (with DISCUSS and COMMENT)

Warning: External Sender - do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Roman,

Thanks for the review, replies inline as jhead>>

From: Roman Danyliw via Datatracker <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, December 16, 2025 at 11:59 AM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Roman Danyliw's Discuss on draft-ietf-rift-kv-tie-structure-and-processing-06: (with DISCUSS and COMMENT)
Roman Danyliw 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!Br7gZGyc8mgreZgRCo88d5hRUzI4jBEuq8ovReW1OC5NIUh__ZgjGyFy69upbciR6n7oDzjlaCRTYg$<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!Br7gZGyc8mgreZgRCo88d5hRUzI4jBEuq8ovReW1OC5NIUh__ZgjGyFy69upbciR6n7oDzjlaCRTYg$>
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!Br7gZGyc8mgreZgRCo88d5hRUzI4jBEuq8ovReW1OC5NIUh__ZgjGyFy69upbciR6n7oDzjAVh037Q$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-rift-kv-tie-structure-and-processing/__;!!NEt6yMaO-gk!Br7gZGyc8mgreZgRCo88d5hRUzI4jBEuq8ovReW1OC5NIUh__ZgjGyFy69upbciR6n7oDzjAVh037Q$>



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

** Section 3.1.1
   All implementations SHOULD use the Appendix A.1 Thrift model

This text makes Appendix A.1 normative.  As such, the specification which
describes the formal syntax, [THRIFT], needs to be normative.

      jhead>> This has been adjusted.

** What is RFC2119 language governs Appendix A.1?

-- Section 3.1.1 says “All implementations SHOULD use the Appendix A.1 Thrift
model”

-- A.1 says “This section contains the Thrift model that MAY be used to test
southbound Key-Value tie-breaking based on System ID.”

How should these SHOULD and MAY statements be composed?

      jhead>> Other reviewers identified similar issues. I’m paraphrasing here, but the new version states something like:  “MUST support the tie break sub-type and SHOULD use the Thrift model"

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

Thank you to Stewart Bryant for the GENART review.

** Section 3.  Editorial.
   *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".

I’ll note one colloquial expression (“northbound”) is being defined by another
(“toward the top of the fabric”).  Consider if you want to reference something
more formal..

      jhead>> We were asked to do something similar in the base RIFT spec (RFC9692) as well.
      jhead>> I could informally refer to it, something like “NOTE: Like [RFC9692], this document uses terms to denote directionality…” but for those coming from reading RFC9692, the colloquial language will be clearer and for those who are only reading this spec without quite as much context, a fair mental tradeoff for the lesson in IP fabrics.

** Section 3.2
    Key
   Targets are 64-bits in length with a valid range of 0 -
   18446744073709551615 (2^64-1), this will reduce the chances that Key
   Target values collide.

Why does a large value range necessarily reduce the chances that the Key Target
values don’t collide without guidance on choosing this value?  For example, if
everyone starts with 1, there will be collision.  Is there implicit guidance to
choose this value randomly?

      jhead>> You’re right, the language about reducing collisions isn’t necessary, I’ll remove it.
      jhead>> The gist though is that the normative algorithm makes use of the RIFT System ID which SHOULD be unique if implemented as specified (https://www.rfc-editor.org/rfc/rfc9692.html#name-automatic-system-id-selecti)