Re: [Cbor] Deprecating tags and Ethernet address in draft-ietf-cbor-network-addresses-09: (with DISCUSS and COMMENT)

[Donald Eastlake <[e-mail]>]

Hi,

On Tue, Oct 5, 2021 at 6:57 PM Erik Kline <[e-mail]> wrote:

> Will there be cleverness like reusing the RFC 7043 DNS RR values
> <https://datatracker.ietf.org/doc/html/rfc7043#section-7> for the new
> tags?  ;-)
>

<de> Well, that certainly could be done, but I don't think it is the right
thing. With RRs, it is good to have a narrow type of value (RRDATA). Almost
certainly, someone retrieving from the DNS is going to want a 48 bit or,
less commonly, a 64 bit MAC address (Infiniband, IEEE 801.15.4 (ZigBee),
and IEEE 1394 (FireWire) use 64-bit MAC addresses). If both were returned
in response to a DNS query, it would probably require a little more
complexity in the client. On the other hand, I don't think that applies so
much to someone parsing CBOR. Also, while there is no current use of other
length MAC addresses, some years ago there was a movement towards 128 bit
MAC addresses although that seems to have been abandoned. Anyway, I think a
single MAC address tag with variable length byte string value would be best.

<de> Perhaps there should also be a second tag to identify 24-bit OUI/CID
values.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

On Tue, Oct 5, 2021 at 3:02 PM Donald Eastlake <[e-mail]> wrote:
>
>> Hi,
>>
>> I am in the process of revising RFC 7042. See
>> https://datatracker.ietf.org/doc/draft-eastlake-rfc7042bis/
>>
>> Perhaps rfc7042bis should specify a CBOR tag for MAC addresses. I'd be
>> happy to add that.
>>
>> Thanks,
>> Donald
>> ===============================
>>  Donald E. Eastlake 3rd   [phone] (cell)
>>  2386 Panoramic Circle, Apopka, FL 32703 USA
>>  [e-mail]
>>
>>
>> On Tue, Oct 5, 2021 at 12:59 PM Michael Richardson <[e-mail]>
>> wrote:
>>
>>>
>>> {another area review, this one from Donald, which never made it to my
>>> inbox. This seems to happen on and off for me. I know it's a local
>>> issue. sigh}
>>>
>>> Opened as issue:
>>> https://github.com/cbor-wg/cbor-network-address/issues/9
>>>
>>> I guess that I'd like to thank the IESG, ADs and Donald Eastlake for
>>> confirming for me, why I didn't want to say ANYTHING about tags 260 and
>>> 261 :-)
>>>
>>> I think that there was a fourth comment which I've misplaced, maybe from
>>> Barry, about what if you did want to tag an ethernet address.
>>> I don't need to do that, if there is someone who does, maybe they could
>>> speak up?
>>> Tag 260 still works, but maybe you want another tag.
>>>
>>> First, since some previous review a week ago, the text now says
>>>
>>>   ## Tags 260 and 261
>>>
>>>   IANA is requested to add the note "DEPRECATED in favor of 52 and 54
>>> for IP
>>>   addresses" to registrations 260 and 261
>>>
>>>
>>> ... the document does not deal with Ethernet Addresses.
>>>
>>>
>>>   According to this document, there currently exists a method for
>>>   encoding 48- and 64-bit MAC addresses using CBOR tag 260 but that
>>>   method will be deprecated. Shouldn't the draft preserve some
>>>   non-deprecated way of encoding MAC addresses?
>>> ** 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
>>> 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.
>>>
>>> --
>>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
>>> consulting )
>>>            Sandelman Software Works Inc, Ottawa and Worldwide
>>>
>>>
>>>
>>>
>>>