[Last-Call] Re: Genart last call review of draft-ietf-bfd-large-packets-13

[Dan Romascanu <dromasca@xxxxxxxxx>]

This is fine with me, maybe this is worth explaining in text.

Regards,

Dan

On Fri, Dec 6, 2024 at 5:31 PM Reshad Rahman <reshad@xxxxxxxxx> wrote:

Hi Dan,

Thanks for the review. One response inline.

On Friday, December 6, 2024 at 04:21:35 AM EST, Dan Romascanu via Datatracker <noreply@xxxxxxxx> wrote:

Reviewer: Dan Romascanu

Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area

Review Team (Gen-ART) reviews all IETF documents being processed

by the IESG for the IETF Chair.  Please treat these comments just

like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-bfd-large-packets-13

Reviewer: Dan Romascanu

Review Date: 2024-12-06

IETF LC End Date: 2024-12-09

IESG Telechat date: Not scheduled for a telechat

Summary:

Ready with Issues

This document extends the BFD functionality for checking connectivity between

two systems with testing the capability of carrying a payloads of a particular

size. It specifies how to implement such a mechanism using BFD in Asynchronous

mode.It also includes YANG modules for managing this mechanism.

This is a clear, well-written document. It is almost Ready with one minor issue

(which may be just a clarification issue) and a couple of editorial nits.

Major issues:

Minor issues:

1. Section 4.2

'In the case multiple BFD clients desire to test the same BFD

  endpoints using different bfd.PaddedPduSize parameters,

  implementations SHOULD select the largest bfd.PaddedPduSize parameter

  from the configured sessions. '

Why a SHOULD and not a MUST?

<RR> This is because (for example) an implementation may decide to use a smaller bfd.PaddedPduSize if the session is not coming up with the largest bfd.PaddedPduSize (and then retry periodically with the largest value). This is all implementation specific (and similar to what is done for BFD timer values).

Regards,

Reshad.

Nits/editorial comments:

1. Section 4.2

'Since the consideration is path MTU, BFD sessions using this feature

  only need to use a bfd.PaddedPduSize appropriate to exercise the path

  MTU for the desired application.

2. I am not sure about Appendix A. If this is useful information, why not

include it in the body of the document. If not, eliminate it.

This sentence seems to need some syntax clean-up.

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx