Re: [Rift] Rtgdir last call review of draft-ietf-rift-rift-20

[Jordan Head <[e-mail]>]

Hi Loa,

Thank you very much for the review.

My comments are inline as jhead>>

Jordan



Juniper Business Use Only
From: Loa Andersson via Datatracker <[e-mail]>
Date: Tuesday, March 19, 2024 at 5:24 AM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Rtgdir last call review of draft-ietf-rift-rift-20
[External Email. Be cautious of content]


Reviewer: Loa Andersson
Review result: Has Nits

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see https://urldefense.com/v3/__https://wiki.ietf.org/en/group/rtg/RtgDir__;!!NEt6yMaO-gk!BRuyr5rrXI7fzEEwSLkBFPHxwxMpAQ2JqcFYDfAidh4TTICD4Pz1ksoGTHCoSzGMntg0TwEwstFA9w$<https://urldefense.com/v3/__https:/wiki.ietf.org/en/group/rtg/RtgDir__;!!NEt6yMaO-gk!BRuyr5rrXI7fzEEwSLkBFPHxwxMpAQ2JqcFYDfAidh4TTICD4Pz1ksoGTHCoSzGMntg0TwEwstFA9w$>

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-rift-rift-20 (the current version is -20)
Reviewer: Loa Andersson
Review Date: 2024-03-19
IETF LC End Date:
Intended Status: Standards Track

Summary:

This document is basically ready for publication (with nits) ; though I found it a bit
hard to read.

- at least for me the appendixes contain info that was useful when it
  came to understand the document. This could be mentioned early in the
  document. Admittedly the Readers Digest does a good work, but it is
  quite a bit into the document.


Document Overview:

This document defines a routing protocol for Clos and fat tree network
topologies optimized towards control plane state efficiency and a
minimum of configuration and operational complexity.

Note: One have to get far into the document (even into appindixes) before
you understand the specification of that protocol

Comments:

The draft is long (189 pages), and it takes time to get through all the
details. That said the authors does a good job, it is more that the
topic is new and fairly complicated. Especially the "Readers Disgest"
section is useful and I had to return to it serval times,

jhead>> Ah yes, I think this comes with the territory (as you said, it is a new protocol). I’m glad to hear that the Reader’s Digest section was useful.

Major Issues:

None

Minor Issues

Abstract

The abstract of a bit thin, I can't really get what it is asll about
from just reading the abstract, and that it what is there for, right?
jhead>> We originally listed the various optimizations made by RIFT in the abstract, but it was quite a long list, and well, not very abstract. In working with other reviewers (AD, etc.) it was decided that a more concise approach was better for the reader.

Nits:

There is a long list of nits found by the nits-tool (not running
verbose), please fix those!
jhead>> The majority of these are a byproduct of using the --expand flag when running xml2rfc before submission (this is required for our document due to the use of SVGs). I have already started combing through and addressing the other ones, however.

In the abstract you say "clos and fat tree topologies", in the the
Terminology section you say "This document uses the terms Clos and
Fat Tree interchangeably".
Should the abstract asy "clos or fat tree topologies"?
Caveat: This is a grammar comment and I do not normally make grammar
comments :)!
jhead>> I agree, good catch.

You mixed "terms" and "abbreviations", have concidered two lists?

jhead>> They are all ultimately terms that are used in the document, some just happen to be abbreviations until we expand them on first-use. I don’t think having two separate lists would make the document easier to read.

In section 5.3.1 you use "acronym", I think the preferred word is
"abbreviation".
All acronyms are abbreviations, but not all abbreviations are acronyms.

jhead>> I presume you mean 5.2.1 (as we don’t have a 5.3.1) where we say “This section describes the terminology and acronyms…”. I’ll change acronyms to abbreviations as it is more accurate.

One question on the policy defintion in the IANA registries, can you
have a reference to an Appendix in the IANA registry?

jhead>> I don’t know the answer to your specific question, however IANA has had several discussions with Tony so that the spec meets their needs.

I have not found any other nits.


/Loa


--
Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]