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

[Barry Leiba <[e-mail]>]

Thanks for the quick reply, and I've put my approval n the PR.

b

On Mon, Jul 19, 2021 at 11:44 AM Carsten Bormann <[e-mail]> wrote:
>
> 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
>