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

[Michael Richardson <[e-mail]>]

I'm replying again to this email for completeness:
Roman Danyliw via Datatracker <[e-mail]> wrote:
    > ** Section 7.  Recommend generalizing the text.

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

    > NEW
    > This document provides an CBOR encoding for IPv4 and IPv6 address information.
    > Any applications using these encodings will need to consider the security
    > implications of this data in their specific context.  For example, 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.

I took your text as is, in commit 42e5c5cd0f3d7cb87a96908fba441f96391736e3
https://github.com/cbor-wg/cbor-network-address/commit/42e5c5cd0f3d7cb87a96908fba441f96391736e3

    > ** Section 8.3.  Recommend making the text clearer on what’s getting deprecated

    > OLD
    > IANA is requested to add the note "DEPRECATED in favor of 52 and 54
    > for IP addresses" to registrations 260 and 261

    > NEW
    > IANA is requested to add the note "DEPRECATED for use with IP addresses in
    > favor of 52 and 54" to registrations 260 and 261

And this change was made in
https://github.com/cbor-wg/cbor-network-address/commit/de38e39dfa7fce46c567b42332fb578632a6b749


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