Re: [Cbor] Benjamin Kaduk's No Objection on draft-ietf-cbor-network-addresses-09: (with COMMENT)

[Michael Richardson <[e-mail]>]

addressing low-hanging fruit.
Other issues are going to issues.

Benjamin Kaduk via Datatracker <[e-mail]> wrote:
    > This specification defines tags 54 and 52.  These new tags are
    > intended to be used in preference to tags 260 and 261.  They provide
    > formats for IPv6 and IPv4 addresses, prefixes, and addresses with
    > prefixes, achieving an explicit indication of IPv6 or IPv4.  The

    > I'd suggest saying here that the tag number is the differentiator
    > between IPv4 and IPv6 -- that could be helpful to know before we go into
    > the discussion of address/prefix/interface format.  Perhaps "achieving
    > an explicit indication of IPv6 or IPv4 by the tag number"?

Suggested accepted.

    > Section 3.1.3

    > When applied to an array that starts with a byte string, which stands
    > for an IP address, followed by an unsigned integer giving the bit
    > length of a prefix built out of the first "length" bits of the
    > address, they represent information that is commonly used to specify
    > both the network prefix and the IP address of an interface.

    > We say "full-length" down in §3.2 and 3.3 (and in the CDDL), but should
    > we perhaps also say here that this byte string need to be the "natural
    > length" or "full length" for the IP address family in question?

+ The length of the byte string is always 16 bytes (for IPv6) and 4 bytes (for IPv4).

    > Section 5

    > unused_bits = (-prefix_length_in_bits) & 7;
    > if (length_in_bytes > 0)
    > address_bytes[length_in_bytes - 1] &= (0xFF << unused_bits);

    > This looks like it's trying to be C, and the XML agrees.  I think it
    > only has the desired effect when two's-complement representation for
    > signed integers is used, though (this is not guaranteed by C through at
    > least C11, though I have not been closely tracking whether the proposal
    > to make C and C++ two's-complement-only has been adopted), and suggest
    > reformulating to something like:

    > unused_bits = (8 - (prefix_length_in_bits & 7)) % 8;

I'll use your version.

    > Section 5

    > A particularly paranoid decoder could examine the lower non-relevant
    > bits to determine if they are non-zero, and reject the prefix.  This

    > This would have to be done before the clearing done by the previous
    > snippet, of course...

Yes.


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide