Hi Wes,
Thanks for your review and please check inline below for responses.
The changes as discussed below will be updated in the next version of the document.
On Sun, Sep 18, 2022 at 7:15 PM Wes Hardaker <wjhns1@xxxxxxxxxxxxx> wrote:
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.
KT> Ack
- 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.
KT> It is understood that it is the operator that is enabling BFD or BFD strict mode. We can clarify this in a couple of places like the introduction and the procedures sections. I don't think it would help much to insert "operator" at every sentence in the document which discusses enablement. I hope that would address your comment.
- 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.
KT> RFC2328 uses the word "higher" in describing the Init state in section 10.1 but then uses "greater" in the other state descriptions. We will keep the word "higher" in the update Init state, but perhaps change to "greater" in another place where we reference 2-way. in the document.
Thanks,
Ketan
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
