Subject: [Cbor] Iotdir early review of draft-ietf-cbor-network-addresses-05

From: Mohit Sethi via Datatracker <[email-masked]>
Date: Mon, 26 Jul 2021 02:57:12 -0700

Reviewer: Mohit Sethi
Review result: Ready with Issues

In the abstract, perhaps "describes" could be "specifies"/"defines"?

It might make sense to provide references to the definition of tags 260  and
261. I had to look them up.

"was removed in this specification" -> "is removed in this specification"?

"When applied to an array that starts with a number"? Is 'number' the correct
terminology? I confused it with the tag number?

What would happen to tags 260 and 261. Are they now discouraged/forbidden? Are
they meant to co-exist with 52 and 54?

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Jul 2021 13:00:02 +0200

Mohit,

thank you for the fast review!

> In the abstract, perhaps "describes" could be "specifies"/"defines"?

The introduction now says

   This document provides a format for IPv6 and IPv4 addresses,

Something similar might work for the abstract.

> 261. I had to look them up.

The reference should be through the registry, as the RFC will be immutable, and those links might change over time.
(Unfortunately, IANA doesn’t currently provide direct links into individual registrations, only references to entire tables:
https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml#table-tags
… which in this case are about as good as references to the entire registry:
https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml
)

> "was removed in this specification" -> "is removed in this specification"?

Well, “removed” is unclear relative to what anyway.
“Is not provided in…” maybe.

> terminology? I confused it with the tag number?

CBOR has different kinds of numbers, but here we really mean unsigned integer.

> they meant to co-exist with 52 and 54?

We don’t have a way to “deprecate” tags.

See also <https://mailarchive.ietf.org/arch/msg/cbor/6BqK5_jrqyz4JelJNbZ8Uwp3kV0>

So I’d like to keep this document free of such a relative grading.

Grüße, Carsten

---

From: Barry Leiba <[email-masked]>
Date: Mon, 26 Jul 2021 09:42:09 -0400

> So I’d like to keep this document free of such a relative grading.

I generally agree with this... but...

If someone comes to the set of CBOR documents later, with no knowledge
of what's gone on here, they will see 260/261, and they will see
52/54, and they will wonder which to use.  If the working group
collectively says, "We don't care either way; they can choose either,
and we're equally happy," then we're done here.  But if the working
group would rather see such new implementors use 52/54, it would be
useful to have a few words about that in this document, however brief
and however non-normative.

Barry

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Jul 2021 16:19:33 +0200

On 2021-07-26, at 15:42, Barry Leiba <[email-masked]> wrote:
> But if the working

Right.  The intro says about our motivation:

   [RFC8949] defines a number of CBOR Tags for common items.  Tags 260
   and 261 were later defined through IANA.  These tags cover addresses
   (260), and prefixes (261).  Tag 260 distinguishes between IPv4, IPv6
   and Ethernet through the length of the byte string only.  Tag 261 was
   not documented well enough to be used.

   This specification provides a format for IPv6 and IPv4 addresses,
   prefixes, and addresses with prefixes, achieving an explicit
   indication of IPv4 or IPv6.  Prefixes omit trailing zeroes in the
   address.  […]

We could expand that a bit more.

Grüße, Carsten

---

From: Barry Leiba <[email-masked]>
Date: Mon, 26 Jul 2021 10:38:20 -0400

> We could expand that a bit more.

Maybe just a sentence, like, "These new tags should be used in
preference to tags 260 and 261."  Or some such.

b

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Jul 2021 16:45:46 +0200

> preference to tags 260 and 261."  Or some such.

How about “the new tags are intended to be used in preference…”?

We can’t place a SHOULd or SHould or should here, but we can state the intention.

Grüße, Carsten

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 26 Jul 2021 14:52:22 +0000

Hi,

> -----Original Message-----
> From: Iot-directorate <[email-masked]> On Behalf Of Barry
> Leiba
> Sent: 26 July 2021 14:42
> To: Carsten Bormann <[email-masked]>
> Cc: [email-masked]; IETF IoT Directorate <iot-
> [email-masked]>; Mohit Sethi <[email-masked]>;
> [email-masked]
> Subject: Re: [Iot-directorate] [Cbor] Iotdir early review of draft-ietf-cbor-
> network-addresses-05
> 

Would it be an option for this draft to update the description in the IANA registry for 260 and 261 to add text to the description to encourage the use of 52 and 54 in preference?

I have to confess that if I wanted to look at what CBOR tags are defined then I think that the first place that I would think of looking would be the IANA CBOR registry.

Regards,
Rob

---

From: Barry Leiba <[email-masked]>
Date: Mon, 26 Jul 2021 11:26:51 -0400

WFM; thanks.

b

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Jul 2021 20:40:27 +0200

On 2021-07-26, at 17:26, Barry Leiba <[email-masked]> wrote:
> WFM

I have submitted a pull request, with I hope solutions for this entire thread.

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

Review/comments/approval welcome.

Grüße, Carsten

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 27 Jul 2021 12:29:34 +0200

> 52/54, and they will wonder which to use.

For the general case, there is the rough plan to adopt
bormann-cbor-notable-tags, and to add a link to the living WG document
to the registry's introduction, advertising it as a guide / survey /
commentary of the tag landscape.

(IANA has indicated that this should be possible).

This will take a bit of time to execute (notable-tags will need to be
adopted, and doesn't mention cbor-network-addresses yet), but I think
it'll be managable in the interims until IETF112.

BR
c

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Jul 2021 16:45:18 -0400

> Review/comments/approval welcome.

I've merged this, and I can post a new revision today, along with any other
comments that might be made at today's meeting.

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