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

Donald Eastlake <d3e3e3@gmail.com> Wed, 06 October 2021 01:27 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0D33A0F22; Tue, 5 Oct 2021 18:27:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYZPYPCakaaN; Tue, 5 Oct 2021 18:27:01 -0700 (PDT)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988AA3A0F16; Tue, 5 Oct 2021 18:27:01 -0700 (PDT)
Received: by mail-il1-x12b.google.com with SMTP id w10so1174133ilc.13; Tue, 05 Oct 2021 18:27:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/6QHU/ut5/D5KzRBJffmB91re//WXd8LfKD0yFCmwU8=; b=NYet/uGm9pO6+P3ews0vzL/FVzLwFhsVavbsNPENYNUzyIHady9WYLzeaDwU0gj94p ndWNF9L2xJVqqsQzh9zV2/zO9uFEkdI2Ye9D37VonKPzFVHeTP14yRJNehbeCdzxgU2x UeK70hBZB3tkJCHknuDZJh0soDfNyiUvno7pyXTfrvXnyENIIm0p8KwKQP01rG+YOo9K 4I8o92ay9ki7NwJgvTQDrco1vedS8l0/YnDnAlj3ltB1h4aZG3PUq9M9tV2BzRQgN1xC bUZyGBJrty79RvTKurgMFxRNlEdV3O/WMezclArCRnnMcUtqBnqUuVPvObECkiyj8Vbw QARA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/6QHU/ut5/D5KzRBJffmB91re//WXd8LfKD0yFCmwU8=; b=RbBZiXQFMmw/WjrdoT4QkayLU+3Y3JSAyEzZPVwyigJ1MQhqLQqvkgfSHQaZfvU3a4 62dNKBXy3ASgGIlp9yYFnoBTqgJHvqRSHulfhMcNulU/mrIR4KAPF3cb+mC48ODKQrNu +dX9bX/FTVu4IZMZlvW7yIrhmLtw5pzsuLteiIMf6k6YZEtyIfiheTfgPXfuTlJVrqmN WUCsaT5GAq5E2GmwhYu+3ouXUhyMy98L5R9V73QEmz88kj0pYZWGxzWrNedsJsXfoSY6 yYfMIbatSqdN+qiREuLdJAQK/+NmKnmCsEF+nBXuFQMXzx2eAnt2xSXYuytUyU5cdniA FJEQ==
X-Gm-Message-State: AOAM532QfU0aOwR/C/79/jtgb/SKdO3zfh7dG7aVn3kGdcqJzezmqVC0 xz08/Q0Tjy1kXvR6jP4D9PeVb+Kt16LL6Fr4+XQ=
X-Google-Smtp-Source: ABdhPJy8Vg2TPYKUYVAZVVGUCcxzK/dPZl5Uptfzkpmz4E9k+h7qAYcy8eAOcCPfscX2aXxZngWHjUJKoH99hkUMIqE=
X-Received: by 2002:a05:6e02:2142:: with SMTP id d2mr2031106ilv.106.1633483620625; Tue, 05 Oct 2021 18:27:00 -0700 (PDT)
MIME-Version: 1.0
References: <163344085669.17315.998599560097016034@ietfa.amsl.com> <26566.1633453159@localhost> <CAF4+nEEF3Rv=KoiS9DZZUVeXnLPdhT=1qa-CNwJR-CHtk9BhEg@mail.gmail.com> <CAMGpriU2W8oagNocLz50p=qX2rE8tcb2OZ98UUfyZprdmrOdMw@mail.gmail.com>
In-Reply-To: <CAMGpriU2W8oagNocLz50p=qX2rE8tcb2OZ98UUfyZprdmrOdMw@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 5 Oct 2021 21:26:49 -0400
Message-ID: <CAF4+nEGVX2kiBjMXgWbOgW=DP81W5hOXJ96U8TLzS_8GBPghtw@mail.gmail.com>
To: Erik Kline <ek.ietf@gmail.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, draft-ietf-cbor-network-addresses@ietf.org, cbor@ietf.org, Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>, cbor-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f42fff05cda50adb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/rz2Irhu956pVuzCqkTzfhhhEelU>
Subject: Re: [Cbor] Deprecating tags and Ethernet address in draft-ietf-cbor-network-addresses-09: (with DISCUSS and COMMENT)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Oct 2021 01:27:07 -0000

Hi,

On Tue, Oct 5, 2021 at 6:57 PM Erik Kline <ek.ietf@gmail.com> 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   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com

On Tue, Oct 5, 2021 at 3:02 PM Donald Eastlake <d3e3e3@gmail.com> 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   +1-508-333-2270 (cell)
>>  2386 Panoramic Circle, Apopka, FL 32703 USA
>>  d3e3e3@gmail.com
>>
>>
>> On Tue, Oct 5, 2021 at 12:59 PM Michael Richardson <mcr+ietf@sandelman.ca>
>> 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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT
>>> consulting )
>>>            Sandelman Software Works Inc, Ottawa and Worldwide
>>>
>>>
>>>
>>>
>>>