On Tue, Nov 26, 2024, 4:19 PM Ron Bonica wrote:
> Tom,
>
> That thought crossed my mind last week. So, I posted a version 02
> immediately after posting version 01.
>
> The fix is in version 02. Also added you to the acknowledgement section.
>
Ron,
Looks good! I support adoption.
Tom
> Happy
Tom,
That thought crossed my mind last week. So, I posted a version 02 immediately
after posting version 01.
The fix is in version 02. Also added you to the acknowledgement section.
Happy Thanksgiving,
On Thu, Nov 21, 2024 at 7:45 AM Ron Bonica
wrote:
>
> Tom,
>
> Good idea!
>
> We could make it an 8-bit field representing 4 bytes of options.
>
> So:
>
> everything in the header is 8-bit aligned
> we can still support 1,024 bytes of options!
Hi Ron,
Thanks for changing that, but can you align
I’ve reviewed -02 and support it. This seems like a simple and useful
improvement.
T
> On Nov 21, 2024, at 8:19 AM, Ron Bonica - rbonica=40juniper.net at
> dmarc.ietf.org wrote:
>
> Tom,
>
> I have just posted a new version of the draft to address your comment.
>
>
Tom,
I have just posted a new version of the draft to address your comment.
Ron
Juniper Business Use Only
From: Tom Herbert
Sent: Thursday, November 21, 2024 10:17 AM
To: Ron Bonica
Cc:
Tom,
Good idea!
We could make it an 8-bit field representing 4 bytes of options.
So:
*
everything in the header is 8-bit aligned
*
we can still support 1,024 bytes of options!
Ron
Juniper Business Use Only
_
Hi Ron,
>From the draft:
"This field represents the total length of all options contained in
the ICMP Extension Structure. It does not include the length of the
Extension Header. The length is measured in bytes. Legacy
implementations set this field to 0."
Alternatively, could the length be s
