Telechat Review of draft-ietf-spring-segment-routing-policy-16
review-ietf-spring-segment-routing-policy-16-intdir-telechat-bernardos-2022-02-13-00

Request Review of draft-ietf-spring-segment-routing-policy
Requested revision No specific revision (document currently at 22)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2022-02-13
Requested 2022-02-01
Requested by Éric Vyncke
Authors Clarence Filsfils , Ketan Talaulikar , Daniel Voyer , Alex Bogdanov , Paul Mattes
I-D last updated 2022-02-13
Completed reviews Rtgdir Last Call review of -14 by Matthew Bocci (diff)
Secdir Last Call review of -14 by Benjamin M. Schwartz (diff)
Artart Last Call review of -16 by Cullen Fluffy Jennings (diff)
Genart Last Call review of -14 by David Schinazi (diff)
Intdir Telechat review of -16 by Carlos J. Bernardos (diff)
Assignment Reviewer Carlos J. Bernardos
State Completed
Request Telechat review on draft-ietf-spring-segment-routing-policy by Internet Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/qGEDcIJ11sxcc8yeK5omrMjsy10
Reviewed revision 16 (document currently at 22)
Result Ready w/nits
Completed 2022-02-13
review-ietf-spring-segment-routing-policy-16-intdir-telechat-bernardos-2022-02-13-00
I am an assigned INT directorate reviewer for
draft-ietf-spring-segment-routing-policy. These comments were written primarily
for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received. For more details on the INT Directorate,
see https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

The document is very well written and I just have a couple of small comments.

Based on my review, if I was on the IESG I would ballot this document as NO
OBJECTION.

The following are other issues I found with this document that SHOULD be
corrected before publication:

Section 3 makes use of a lot of potentially normative “may” which is not clear
if they are meant to be normative or not.

The following are minor issues (typos, misspelling, minor text improvements)
with the document:

In section 3, when describing the SR-DB, two IGP protocols are mentioned (ISIS
and OSPF). Are those the only ones meant to be supported?

“with the End behavior (as defined in [RFC8986]), of the node” —> I think the
“,” should be removed