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

[Carsten Bormann <[e-mail]>]

On 2021-07-19, at 16:18, Barry Leiba <[e-mail]> wrote:
> 
> Hi, all.  Here's my shepherd review of draft-ietf-cbor-network-addresses-05.

Thank you!

Some editorial work was already done based on Marco’s comments, which partially overlaps yours; so if the comment isn’t mentioned below, we already have done it or did it now.

> 
> What is “the present specification”?  

I love how English doesn’t seem to have a translation for
“Die vorliegende Spezifikation”.

https://www.deepl.com/translator#de/en/die%20vorliegende%20Spezifikation

At least, many people don’t seem to associate the meaning of that with “the present specification”.  “This specification” is always a problem because it may refer to a specification that was just talked about instead of “the present specification”, which is the specification that is present before your eyes.

Anyway, merging the paragraphs got rid of the problem in a natural way.

> — Sections 3.1 and 3.2 —
> 
> There are examples of [prefix-length, addr] and [addr, prefix-length],
> but no examples of just [addr],

(Which would be wrong — we only have `addr`, not `[addr]`.)

Added examples for bare addrs now.
(And reduced the irregularity of the spacing in the examples.)

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

Not very well.
Fixed in Section 4, together with some editorial improvements.


> — 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.  That information, however, is likely to be
>   found in the relevant RFCs anyway, so this is not a significant
>   exposure.

Thanks, much better.

Now https://github.com/cbor-wg/cbor-network-address/pull/7

Grüße, Carsten