Skip to main content

Telechat Review of draft-ietf-cbor-network-addresses-09

Request Review of draft-ietf-cbor-network-addresses
Requested revision No specific revision (document currently at 13)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2021-10-05
Requested 2021-09-28
Requested by Éric Vyncke
Authors Michael Richardson , Carsten Bormann
Draft last updated 2021-10-18
Completed reviews Iotdir Early review of -05 by Mohit Sethi (diff)
Opsdir Early review of -05 by Ron Bonica (diff)
Genart Last Call review of -08 by Robert Sparks (diff)
Intdir Telechat review of -09 by Donald E. Eastlake 3rd (diff)
As the Last Call review was not done... please try to assign another reviewer on this document.

Thank you

Assignment Reviewer Donald E. Eastlake 3rd
State Completed
Review review-ietf-cbor-network-addresses-09-intdir-telechat-eastlake-2021-10-18
Posted at
Reviewed revision 09 (document currently at 13)
Result Ready with Nits
Completed 2021-10-18
I am an assigned INT directorate reviewer for
<draft-ietf-cbor-network-addresses-09.txt>. These comments were
written primarily for the benefit of the Internet Area Directors.
Document editors and shepherd(s) should treat these comments just like
they would treat comments from any other IETF contributor and resolve
them along with any other Last Call comments that have been received.
For more details on the INT Directorate, see

Based on my review if I was on the IESG I would ballot this document

This is a simple document specifying new CBOR tags 54 and 52 for IPv6
and IPv4 where each can be used to encode an address, a prefix, or an
interface (the IP address of the interface plus the local netmask) by
clever use of the encoding of the content of the tag. The document
also deprecates CBOR tags 260 and 261 which were previously intended
for this use.

The following are issues I found with this document that SHOULD be
resolved before publication:

  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?

The following are minor issues with the document:

  I think it would be useful for readers not familiar with CBOR to
  include a sentence such as the following somewhere near the
  beginning of the document: "CBOR tag numbers are given as decimal

  This document does not believe in the Oxford comma, but I believe in
  it as does the RFC Editor so they can be added now or in RFC

  I think the wording of the first paragraph could be improved. Also,
  while it gives a reason for deprecating tag 261, it does not give
  any reason for deprecating tag 260. Here is my quick attempt at a
  possible re-wording:
   [RFC8949] defines a number of CBOR Tags for common items.  Tags 260
   and 261 were later defined through IANA [IANA.cbor-tags].  These tags
   cover addresses (260), and prefixes (261).  Tag 260 distinguishes
   between IPv6, IPv4 and Ethernet through the length of the byte string
   only.  Tag 261 was not documented well enough to be used.
   [RFC8949] defines a number of CBOR Tags for common items. Tags 260
   and 261 were later defined in drafts listed with IANA
   [IANA.cbor-tags]. These tags were intended to cover addresses (260)
   and prefixes (261). Tag 260 distinguishes between IPv6, IPv4, and
   MAC [RFC7042] addresses only through the length of the byte string
   making it impossible, for example, to drop trailing zeros in the
   encoding of IP addresses. Tag 261 was not documented well enough to
   be used.

  Three times: "to be used" -> "for use"

  In Section 6, should the "recommended" in the first sentence be in
  all capital letters?

  I would delete all occurrences of "Note that " except for the one
  in the boilerplate :-)

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA