Skip to main content

Last Call Review of draft-ietf-ospf-sr-yang-22

Request Review of draft-ietf-ospf-sr-yang
Requested revision No specific revision (document currently at 30)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2023-11-30
Requested 2023-10-31
Requested by Acee Lindem
Authors Yingzhen Qu , Acee Lindem , Zhaohui (Jeffrey) Zhang , Ing-Wher (Helen) Chen
I-D last updated 2023-11-29
Completed reviews Rtgdir Last Call review of -22 by Julien Meuric (diff)
Yangdoctors Last Call review of -28 by Reshad Rahman (diff)
Yangdoctors Early review of -20 by Reshad Rahman (diff)
Assignment Reviewer Julien Meuric
State Completed
Request Last Call review on draft-ietf-ospf-sr-yang by Routing Area Directorate Assigned
Posted at
Reviewed revision 22 (document currently at 30)
Result Has nits
Completed 2023-11-29

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 

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-ospf-sr-yang-22
Reviewer: Julien Meuric
Review Date: 2023-11-29
Intended Status: Standard Tracks


This document is basically ready for publication but has nits that 
should be considered prior to publication.


- The very first paragraph of the introduction/overview section 
summarizes the basis of YANG, XML, JSON, data models... I believe we are 
now far beyond those general considerations and we could skip that 
- In the grouping "ospfv3-lan-adj-sid-sub-tlvs" (p23), the leaf 
"neighbor-router-id" uses type "dotted-quad". This is consistent with 
RFC 8666 which specifies the associated OSPFv3 TLV, but we had a 
discussion about the type for router-id in the TE YANG models. The 
current resolution on TEAS side will be to consider a union of 
dotted-quad and ipv6-address. I wonder how much RTGWG would be ready to 
consider a superset of the existing OSPFv3 TLVs.


- Multiple times in description: s/SR specific/SR-specific/
- Multiple times in description: s/flag bits list/flag list/
- Multiple times in description: s/flags list/flag list/
- The description fields use a mix of "Adj sid", "adj sid", "Adj SID"... 
sometimes with hyphens (not to mention the full expansions). A single 
phrase should be chosen and used all along the module.
- A few description starts with "The..." (e.g., in 
"ospfv2-extended-prefix-range-tlvs" on p 19, or v3 on p 22) while most 
of them don't. For consistency, it should be dropped from every brief 

- In the grouping "ospfv3-prefix-sid-sub-tlvs" (p 21 and all resulting 
pieces of tree): s/perfix-sid-sub-tlvs/prefix-sid-sub-tlvs/
- In the same grouping, the description of the container should be 
"Prefix SID sub-TLV *list*." (and "Prefix SID sub-TLV." reserved for the 
following list element).
- In the container "ti-lfa" (p 25): s/Enables TI-LFA/Enable TI-LFA/ [Not 
wrong, but should be consistent with others.]
- In the same container (p 26): "s/Topology Independent Loop Free 
Alternate/Topology-Independent Loop-Free Alternate/
- In section 3 (p 37): s/The YANG modules [...] define/The YANG module 
[...] defines/
- In the same section: s/in the modules/in the module/
- In the same section: s/Module ietf-ospf-sr/The module ietf-ospf-sr/