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

[[e-mail]]

Jordan,

I'm mostly happy with your replies.

One thing is my comment on the Abstract, I think it is valid.
I'm not asking for more details, rather is more overview.

The abstract is intended to be stand alone, it shall be possible to cut
it out and pasted in a relevant context (e.g. a test on "What are the
RIFT RFCs all about" and still be understood stand alone.

When I started to write my first Abstracts Scott Bradner told me, think
of your own manager and write a text so he can understand what the draft
is about.

That is what I'm looking for, not more details.

/Loa



> 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]
>
> --
> last-call mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call
>