Hi,
I'm going to split up the discussion a bit so we can tackle it
in pieces. We need to do a holistic review but I think that we
need to first get some consensus on some specifics. I'm going
to start with the address of the device in the payload block.
(I'll keep going till the flight lands. ;-)
Section 4.2 states:
==============
4.2. Building the Payload Block
The payload block is built when a new reboot session is started.
There is a one-to-one correspondence of reboot sessions to payload
blocks. That is, each reboot session has only one payload block,
regardless of how many signature groups it may support.
The payload block consists of the following
a. Unique identifier of sender; by default, the sender's 128-bit IP
address encoded in base-64.
==============
Why not just leave this as the "decimal-dot" (IPv4) or "decimal-colon"
(IPv6) representation? For example, if the sender's address is 10.1.1.1
then it will be 0x0a010101 in the IP header but will be "10.1.1.1 " in
the payload. This may drive the total number of signatures down to 6 in
the payload block but I think that I might rather see the address in
cleartext rather than in base-64. If that makes sense, the representations
are defined in STD-13 (IPv4) and RFC-2373 (IPv6).
Thanks,
Chris
At 02:58 PM 10/1/2001 -0700, Jon Callas wrote:
>At 11:21 AM +0200 10/1/01, Balazs Scheidler wrote:
>
>>- Payload blocks: IP addresses are not 128 bits, unless we are speaking
>> about ipv6
>>
>
>This isn't a bug, it's a feature. There's a trivial encoding of IPv4
>addresses into IPv6 addresses. We need to leave room for IPv6 if we expect
>to be on the Standards Track.
