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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-cbor-network-addresses-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cbor-network-addresses/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

What should a recipient do if they encounter something in a form that is
expected to include a "natural length" byte string for the IP address
family indicated, but the byte string is a different length?  Do we just
need to say that it is "invalid" and thereby invoke the core CBOR rules
that require protocols to specify how their decoders handle invalid
data?  Or is even that implicit from the CDDL?

In light of the genart reviewer's comment, I think we should say
something like "this specification does not deal with Ethernet
addresses, and tag 260 remains available for that usage" to clarify that
we are not deprecating use of that tag for Ethernet addresses.

   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"?

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?

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;

(This would be DISCUSS level if it was the only specification for the
behavior, but since it is "or simply", it seems more illustrative in
intent.)

NITS

Section 3.2

   54([h'20010db81234DEEDBEEFCAFEFACEFEED', 56])

DEADBEEF (rather than DEEDBEEF) is in somewhat common usage as a pattern
for indicating "tainted" memory in various sanitizer codes...

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...