[Cbor] Document shepherd review of draft-ietf-cbor-network-addresses

[Barry Leiba <[e-mail]>]

Hi, all.  Here's my shepherd review of draft-ietf-cbor-network-addresses-05.

— Section 1 —

I would merge the one-sentence first paragraph into the second paragraph.

   Tag 260 and tag 261 was later defined through IANA.

“were”, plural.  I might also say “Tags 260 and 261” rather than
repeating the word “tag”, but keep this as you please.

   The present specification achieves an explicit indication of IPv4 or
   IPv6, and the possibility to omit trailing zeroes.

What is “the present specification”?  The one associated with the IANA
registration (I don’t think that’s what you mean, as there's no detail
there)?  Or this document?  Assuming the latter, it would be a lot
clearer if you just merged this sentence into the following paragraph,
where you already talk about what “this document” does.  If you really
mean something else, it could use a reference citation and rewording
of “the present specification”.

   Due to the complexity of testing the value of
   omitting trailing zeros for addresses was considered non-essential
   and support for that was removed in this specification.

This seems hard to parse.  As I read this, I see “testing the value”
as a unit, but I think you mean for there to be a comma after
“testing”?  Or maybe you do mean that “testing the value” is complex,
but then the word “of” seems wrong.  Can you reword this to clean that
up?

— Sections 3.1 and 3.2 —

There are examples of [prefix-length, addr] and [addr, prefix-length],
but no examples of just [addr], so it’s easy to miss that that’s also
valid.  It would be useful to add an example after this paragraph:

   An IPv6 address is to be encoded as a sixteen-byte byte string
   (Section 3.1 of [RFC8949], major type 2), enclosed in Tag number 54.

…and similarly for Section 3.2.

— Section 4 —

   An encoder may omit as many right-hand (trailing) bytes which are all
   zero as it wishes.

How does this fit with “Trailing zero bytes MUST be omitted.” in
Sections 3.1 and 3.2?

— Section 7 —

   Identifying which byte sequences in a protocol are addresses may
   allow an attacker or eavesdropper to better understand what parts of
   a packet to attack.

   Reading the relevant RFC may provide more information, so it would
   seem that any additional security that was provided by not being able
   to identify what are IP addresses falls into the security by
   obscurity category.

Does this mean the following (and if so, might this be a better way to say it?):

   Identifying which byte sequences in a protocol are addresses may
   allow an attacker or eavesdropper to better understand what parts of
   a packet to attack.  That information, however, is likely to be
   found in the relevant RFCs anyway, so this is not a significant
   exposure.

-- 
Barry