Re: [Last-Call] Secdir last call review of draft-ietf-lsr-ospf-bfd-strict-mode-07

[Ketan Talaulikar <[e-mail]>]

Hi Wes,

The update version just posted includes the changes we discussed below:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode-08

Thanks,
Ketan


On Tue, Sep 20, 2022 at 7:50 PM Ketan Talaulikar <[e-mail]>
wrote:

> 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 <[e-mail]> 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
>
>
>