Hello Barry, hello Jürgen,
I've just uploaded a -12, and Marco has been very quick to update the
write-up.
All the points of the reviews have been addressed, and being nits
probably don't warrant further mention outside the changelog of the -12
(copied below for convenience).
The nontivial point was the lack of explanation about the number given
for OK-to-send responses. It has been recalculated with more
conservative numbers, experssed in what is hoped to be easier to consume
for implementation developers. For the "factor 3" that plays into it it
now refers to the WIP QUIC draft. It's giving the numbers as guidance in
case there's no better basis for making a more situation-adjusted and
more informed decision.
With that, the document should be good to go ahead.
Best regards, and thanks for all your input
Christian
---
* Changes since draft-ietf-core-echo-request-tag-11 (addressing
GenART, TSVART, OpsDir comments)
- Explain the size permissible for responses before amplification
mitigation by referring to the QUIC draft for an OK factor, and
giving the remaining numbers that led to it. The actual number
is reduced from 152 to 136 because the more conservative case
of the attacker not sending a token is considered now.
- Added a definition for "freshness"
- Give more concrete example values in figures 2 and 3 (based on
the appendix suggestions), highlighting the differences between
the figures by telling how they are processed in the examples.
- Figure with option summary: E/U columns removed (for duplicate
headers and generally not contributing)
- MAY capitalization changed for consistency.
- Editorial changes (IV acronym expanded, s/can not/cannot/g)
- Draft ietf-core-stateless has become RFC8974
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
