Re: [Last-Call] Opsdir last call review of draft-ietf-core-echo-request-tag-11

[Carsten Bormann <[e-mail]>]

Hi Juergen,

thank you for this review.  I was intrigued by one of your nits:

> - The number of 152 bytes mentioned in section 2.4:

I think you are discussing this paragraph:

       *  Amplification mitigation should be used when the response
          would be more than three times the size of the request,
          considering the complete frame on the wire as it is typically
          sent across the Internet.  In practice, this allows UDP data
          of at least 152 Bytes without further checks.

I think this is trying to say that responses of 152 bytes are not requiring amplification mitigation under this rule, so there seems to be an assumption that the request would have been about 152/3 ~ 51 bytes, which is close to, but smaller than an 40-byte IP, an 8-byte UDP, and a minimal 4-byte CoAP header, which is 52 bytes, but then there are Ethernet headers and trailers, making the request 70 bytes (or 50 bytes for IPv4, which then becomes the minimum Ethernet frame of 64 bytes).  The maximum response would then be 3*70=210 bytes on the wire, minus 18+48 bytes Ethernet/IP/UDP, leading to 154 bytes “UDP Data”.  I don’t know.

>  3*152 would be 456 octets, I am not sure why this is the "typical
>  size of a frame on the wire sent across the Internet”.

Typical size of the frame (or packet?) of the request, not of any packet on the Internet.

I’m sure this could be phrased in a way that is a bit easier to follow.

The number to be explained is not so much the 152 (the exact value of which I don’t really understand), but the three.

> Either
>  explain how you obtained this number of consider removing it in case
>  it does depend on assumptions that are not guaranteed to be always
>  true. One option could also be to simply drop this sentence.

Indeed.

> - The difference between Figure 2 and Figure 3 is rather subtle.

Very subtle.  “Cthulhu!” vs. “Comic Sans” (and t vs. e).

Grüße, Carsten