[Last-Call] Re: Genart last call review of draft-ietf-bmwg-benchmarking-stateful-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for your very quick response Gábor.

Everything below looks fine. Answers to your questions inline.

On 5/22/24 12:25 PM, Gábor LENCSE wrote:
Dear Robert,

Thank you very much for your review and comments. Please see my answers inline.

2024.05.22. 18:30 keltezéssel, Robert Sparks via Datatracker írta:
Reviewer: Robert Sparks
Review result: Ready with Nits

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-bmwg-benchmarking-stateful-06

Reviewer: Robert Sparks
Review Date: 2024-05-22
IETF LC End Date: 2024-05-22
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as an Informational RFC with nits

Nits/editorial comments:

There are places in the text that say "The authors are aware" - the
construction seems out of place for a consensus IETF stream document - I'm not
sure if this was the resolution of an argument, or just text that could be
further changed to "Note that" or something similar.
In fact they are the consequences of my academic background. This _expression_ looks good in research papers (at least I believe so).

I have searched the text for those expressions and I found the following ones: In the Introduction:
   However, none of them discussed, how to apply [RFC4814] pseudorandom
   port numbers, when benchmarking stateful NATxy (NAT44, NAT64, NAT66)
   gateways.  The authors are not aware of any other RFCs that address
   this question.
In this case, I believe that it is now fair to leave this sentence as it was during WGLC. I mean that the authors should take full responsibility for this statement and should not try to make BMWG members responsible for it after WGLC.
In section 3.1:
   Note: The authors are fully aware of [RFC6890] special purpose IP
   address ranges.  The [RFC1918] private IP addresses are used to
   facilitate an easy understanding of the example.  And the authors
   consider the usage of the IP addresses reserved for benchmarking
   absolutely legitimate.
This note is here, because the nit checker pointed out problems and I wanted to emphasize that it was NOT a mistake to use those IP addresses. Perhaps the first sentence is not needed and also the "authors consider" can be removed from the last sentence. I have rewritten the paragraph as follows:
   Note that the [RFC1918] private IP addresses are used to facilitate
   an easy understanding of the example.  And the usage of the IP
   addresses reserved for benchmarking is absolutely legitimate.
(If the RFC Editor recommends the removal of this text, it will be OK for me. It is mainly here to prevent people from believing the false report of the nit checker.) At the end of Section 4.8:
   The authors are aware that the performance of removing the entire
   content of the connection tracking table at one time may be different
   from removing all the entries one by one.
I have changed it to:
   It is noted that the performance of removing the entire content of
   the connection tracking table at one time may be different from
   removing all the entries one by one.

Currently the changes remain in my XML file. I am waiting for one further review and I plan to submit a new version of the draft when all reviews are addressed and they are deemed satisfactory by the corresponding Reviewers.

I support the concerns Michael raised in his tsvart review.
I sent my reply to Michael today. Have you received it? If not, you can check it in the BMWG mailing archive using the following link: https://mailarchive.ietf.org/arch/msg/bmwg/cSUddYnLSHKpA6We6U6WuNRwIiA/
I had not yet seen it - thanks for the direct link, and I'm ok with your responses there.

Please consider reaching out to the RFC-Editor early for how to best represent
the small block of pseudocode in the xml for the document.
Do you mean that presenting pseudo-code as "artwork" in Figure 5 is not best solution and it should be changed?
Yes, that vs code or some other construct. The RPC has worked through this several times with other drafts and has guidance to provide. I am not sure I would get it right myself at the moment, so again, I suggest reaching out to them early.

Once again, thank you very much for your review and comments, which helped us to improve our Internet Draft.

Best regards,

Gábor Lencse

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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux