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,I had not yet seen it - thanks for the direct link, and I'm ok with your responses there.
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:
In fact they are the consequences of my academic background. This _expression_ looks good in research papers (at least I believe so).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.
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 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 support the concerns Michael raised in his tsvart review.
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.
Do you mean that presenting pseudo-code as "artwork" in Figure 5 is not best solution and it should be changed?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.
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
