Skip to main content

Last Call Review of draft-ietf-lsr-ospf-bfd-strict-mode-07
review-ietf-lsr-ospf-bfd-strict-mode-07-secdir-lc-hardaker-2022-09-23-00

Request Review of draft-ietf-lsr-ospf-bfd-strict-mode
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2022-09-20
Requested 2022-09-06
Authors Ketan Talaulikar , Peter Psenak , Albert Fu , Rajesh Shetty
I-D last updated 2022-09-23
Completed reviews Rtgdir Last Call review of -04 by Andy Smith (diff)
Secdir Last Call review of -07 by Wes Hardaker (diff)
Genart Last Call review of -07 by Russ Housley (diff)
Assignment Reviewer Wes Hardaker
State Completed
Request Last Call review on draft-ietf-lsr-ospf-bfd-strict-mode by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/2QPh4DZ-h6PG7hgGVq-yOp2K1FM
Reviewed revision 07 (document currently at 10)
Result Ready
Completed 2022-09-18
review-ietf-lsr-ospf-bfd-strict-mode-07-secdir-lc-hardaker-2022-09-23-00
Reviewer: Wes Hardaker
Review result: Ready

I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Security Area
Directors.  Document authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.

Document: draft-ietf-lsr-ospf-bfd-strict-mode-07
Reviewer: Wes Hardaker
Review Date: 2022-09-18
IETF LC End Date: 2022-09-20

Summary: Ready

Major Concerns: None
Minor Concerns: Just nits and comments

Nits and comments:

- In the introduction you might point to the section numbers where
  future things are defined.  The one that drew my attention was the
  local interface ipv4 address TLV section (3) which is mentioned in
  4th paragraph in the introduction, but the section itself felt like
  it came about suddenly.  I'd add a "(section 3)" tagging to the
  introduction to introduce where it will be discussed later.  But
  this is a very minor nit/suggestion.

- In multiple places it talks about "strict-mode is enabled on the
  link" or similar.  It is unclear from the context where this
  enabling is happening, and I'd be tempted to add a bit more
  operational context such as "strict-mode is enabled by the
  operator..." or similar.

- In the state discussions the phrase "or higher" is used to indicate
  multiple states.  The original OSPF RFC generally uses different
  terminology: "or greater".  It might be wise to switch to the
  original terminology instead.