Skip to main content

Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes
RFC 9164

Revision differences

Document history

Date Rev. By Action
2021-12-13
13 (System)
Received changes through RFC Editor sync (created alias RFC 9164, changed title to 'Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses …
Received changes through RFC Editor sync (created alias RFC 9164, changed title to 'Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes', changed abstract to 'This specification defines two Concise Binary Object Representation (CBOR) tags for use with IPv6 and IPv4 addresses and prefixes.', changed pages to 10, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2021-12-13, changed IESG state to RFC Published)
2021-12-13
13 (System) RFC published
2021-12-06
13 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-12-02
13 (System) RFC Editor state changed to AUTH48
2021-11-11
13 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-11-05
13 Christian Amsüss Added to session: IETF-112: cbor  Thu-1430
2021-10-30
13 Bernie Volz Closed request for Last Call review by INTDIR with state 'Overtaken by Events'
2021-10-25
13 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-10-25
13 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2021-10-25
13 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-10-25
13 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-10-23
13 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2021-10-23
13 Tero Kivinen Assignment of request for Last Call review by SECDIR to Daniel Franke was marked no-response
2021-10-22
13 (System) IANA Action state changed to Waiting on Authors
2021-10-22
13 (System) RFC Editor state changed to EDIT
2021-10-22
13 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-10-22
13 (System) Announcement was received by RFC Editor
2021-10-22
13 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-10-22
13 Amy Vezza IESG has approved the document
2021-10-22
13 Amy Vezza Closed "Approve" ballot
2021-10-22
13 Amy Vezza Ballot approval text was generated
2021-10-22
13 (System) Removed all action holders (IESG state changed)
2021-10-22
13 Francesca Palombini IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2021-10-22
13 Carsten Bormann New version available: draft-ietf-cbor-network-addresses-13.txt
2021-10-22
13 (System) New version accepted (logged-in submitter: Carsten Bormann)
2021-10-22
13 Carsten Bormann Uploaded new revision
2021-10-20
12 Christian Amsüss Added to session: interim-2021-cbor-19
2021-10-20
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-10-20
12 Carsten Bormann New version available: draft-ietf-cbor-network-addresses-12.txt
2021-10-20
12 (System) New version accepted (logged-in submitter: Carsten Bormann)
2021-10-20
12 Carsten Bormann Uploaded new revision
2021-10-18
11 Donald Eastlake Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Donald Eastlake.
2021-10-13
11 Carlos Bernardos Assignment of request for Last Call review by INTDIR to Zhen Cao was marked no-response
2021-10-11
11 Amanda Baber IANA Experts State changed to Expert Reviews OK from Reviews assigned
2021-10-11
11 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-10-09
11 John Scudder
[Ballot comment]
The updated version looks good, thanks!

Text of former DISCUSS below for posterity.

--

Thanks for this document. In general I found it …
[Ballot comment]
The updated version looks good, thanks!

Text of former DISCUSS below for posterity.

--

Thanks for this document. In general I found it easy to read, blessedly concise, and useful. I do have one concern with how you treat the covert channel concern you raise, which I'm making a DISCUSS (which I think will be easily cleared).

Section 4 says:

  even though variations like:

  54([44, h'20010db81233'])
  54([45, h'20010db8123f'])

  would be parsed in the exact same way; they MUST be considered
  invalid.

You choose to use a RFC 2119 keyword here, and this is in the encoder section, so presumably you are insisting that the encoder MUST... what? You already said, in an earlier paragraph, that the encoder MUST set the trailing bits to zero, so I can't figure out what the quoted text is telling me to do. (Presumably any compliant encoder won't produce the depicted values, and an encoder that's noncompliant for the purpose of deliberately exfiltrating data using this covert channel won't be put off by this MUST.)

Then in Section 5 we have:

  A particularly paranoid decoder could examine the lower non-relevant
  bits to determine if they are non-zero, and reject the prefix.  This
  would detect non-compliant encoders, or a possible covert channel.

The fairly dismissive tone ("paranoid decoder could"), not to mention the preceding pseudocode, suggests that you have no real expectation the decoder will do anything to "consider invalid" values with nonzero low bits. So probably the MUST from Section 4 isn't meant to apply to the decoder.

In short I don't understand what that clause in Section 4 is telling me to do. One fix would simply be to weaken the text, as in

  would be parsed in the exact same way, they should not be
  considered legitimate encodings.
 
P.S.: The semicolon in the quoted text is also either wrong, or I'm even more confused about what's being specified than I thought I was.
2021-10-09
11 John Scudder [Ballot Position Update] Position for John Scudder has been changed to No Objection from Discuss
2021-10-08
11 (System) Changed action holders to Francesca Palombini (IESG state changed)
2021-10-08
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-10-08
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2021-10-08
11 Michael Richardson New version available: draft-ietf-cbor-network-addresses-11.txt
2021-10-08
11 (System) New version approved
2021-10-08
11 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Michael Richardson
2021-10-08
11 Michael Richardson Uploaded new revision
2021-10-07
10 Barry Leiba Closed request for Last Call review by ARTART with state 'Team Will not Review Version'
2021-10-07
10 Barry Leiba Assignment of request for Last Call review by ARTART to Alex Gouaillard was withdrawn
2021-10-07
10 (System) Changed action holders to Carsten Bormann, Michael Richardson, Francesca Palombini (IESG state changed)
2021-10-07
10 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2021-10-07
10 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2021-10-06
10 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document and addressing my previous ballot points (DISCUSS & COMMENT); those points are kept below …
[Ballot comment]
Thank you for the work put into this document and addressing my previous ballot points (DISCUSS & COMMENT); those points are kept below for archiving purposes only.

Special thanks to Barry Leiba for his concise shepherd's write-up but very clear about the WG consensus.

Thank you also to Donald Eastlake for this INT directorate review that I am vastly supporting:
https://mailarchive.ietf.org/arch/msg/int-dir/6Ox8iEBMqXkUoC2aUEF3wi4-c5g/

I hope that this helps to improve the document,

Regards,

-éric


== PREVIOUS DISCUSS (for archive) ==

Generic comment how are link-local address (LLA) with scope encoded ? I would expect CBOR to work also on LLA only networks... At the bare minimum, please state that link-local addresses cannot be encoded with their scope, hence, they cannot represent an interface.

-- Section 3.1.3 --
How can 2 valid link-local addresses (fe80::1%eth0, fe80::1%eth1) can be represented in order to identity two interfaces ?

== PREVIOUS COMMENTS (for archive) ==

I love how your start with IPv6 in section 3 and use the ASCII codes for '6' and '4' ;-)

-- Section 3.2 --
Is there any reason why part of the IPv6 is in lowercase (as in RFC 5952) and the other part in uppercase ? This is confusing to the reader (even if hexadecimal numbers are obviously case insensitive).

== NITS ==

-- Abstract --
Should CBOR be expanded ?
2021-10-06
10 Éric Vyncke [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss
2021-10-06
10 John Scudder
[Ballot discuss]
Thanks for this document. In general I found it easy to read, blessedly concise, and useful. I do have one concern with how …
[Ballot discuss]
Thanks for this document. In general I found it easy to read, blessedly concise, and useful. I do have one concern with how you treat the covert channel concern you raise, which I'm making a DISCUSS (which I think will be easily cleared).

Section 4 says:

  even though variations like:

  54([44, h'20010db81233'])
  54([45, h'20010db8123f'])

  would be parsed in the exact same way; they MUST be considered
  invalid.

You choose to use a RFC 2119 keyword here, and this is in the encoder section, so presumably you are insisting that the encoder MUST... what? You already said, in an earlier paragraph, that the encoder MUST set the trailing bits to zero, so I can't figure out what the quoted text is telling me to do. (Presumably any compliant encoder won't produce the depicted values, and an encoder that's noncompliant for the purpose of deliberately exfiltrating data using this covert channel won't be put off by this MUST.)

Then in Section 5 we have:

  A particularly paranoid decoder could examine the lower non-relevant
  bits to determine if they are non-zero, and reject the prefix.  This
  would detect non-compliant encoders, or a possible covert channel.

The fairly dismissive tone ("paranoid decoder could"), not to mention the preceding pseudocode, suggests that you have no real expectation the decoder will do anything to "consider invalid" values with nonzero low bits. So probably the MUST from Section 4 isn't meant to apply to the decoder.

In short I don't understand what that clause in Section 4 is telling me to do. One fix would simply be to weaken the text, as in

  would be parsed in the exact same way, they should not be
  considered legitimate encodings.
 
P.S.: The semicolon in the quoted text is also either wrong, or I'm even more confused about what's being specified than I thought I was.
2021-10-06
10 John Scudder Ballot discuss text updated for John Scudder
2021-10-06
10 John Scudder
[Ballot discuss]
Thanks for this document. In general I found it easy to read, blessedly concise, and useful. I do have one concern with how …
[Ballot discuss]
Thanks for this document. In general I found it easy to read, blessedly concise, and useful. I do have one concern with how you treat the covert channel concern you raise, which I'm making a DISCUSS (which I think will be easily cleared).

Section 4 says:

  even though variations like:

  54([44, h'20010db81233'])
  54([45, h'20010db8123f'])

  would be parsed in the exact same way; they MUST be considered
  invalid.

You choose to use a RFC 2119 keyword here, and this is in the encoder section, so presumably you are insisting that the encoder MUST... what? You already said, in an earlier paragraph, that the encoder MUST set the trailing bits to zero, so I can't figure out what the quoted text is telling me to do. (Presumably any compliant encoder won't produce the depicted values, and an encoder that's noncompliant for the purpose of deliberately exfiltrating data using this covert channel won't be put off by this MUST.)

Then in Section 5 we have:

  A particularly paranoid decoder could examine the lower non-relevant
  bits to determine if they are non-zero, and reject the prefix.  This
  would detect non-compliant encoders, or a possible covert channel.

The fairly dismissive tone ("paranoid decoder could"), not to mention the preceding pseudocode, suggests that you have no real expectation the decoder will do anything to "consider invalid" values with nonzero low bits. So probably the MUST from Section 4 isn't meant to apply to the decoder.

In short I don't understand what that clause in Section 4 is telling me to do. One fix would simply to weaken the text, as in

  would be parsed in the exact same way, they should not be
  considered legitimate encodings.
 
P.S.: The semicolon in the quoted text is also either wrong, or I'm even more confused about what's being specified than I thought I was.
2021-10-06
10 John Scudder [Ballot Position Update] New position, Discuss, has been recorded for John Scudder
2021-10-06
10 Amanda Baber IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2021-10-06
10 Amanda Baber Asking expert to confirm that revised deprecation note is OK.
2021-10-06
10 Amanda Baber IANA Experts State changed to Reviews assigned from Expert Reviews OK
2021-10-06
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-10-06
10 Michael Richardson New version available: draft-ietf-cbor-network-addresses-10.txt
2021-10-06
10 (System) New version approved
2021-10-06
10 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Michael Richardson
2021-10-06
10 Michael Richardson Uploaded new revision
2021-10-06
10 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Michael Richardson
2021-10-06
10 Michael Richardson Uploaded new revision
2021-10-06
09 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-10-05
09 Zaheduzzaman Sarker
[Ballot comment]
I am curious about Eric’s 2nd discuss point, hence supporting his discuss on that.

I also support Lars’s and Murray’s comments.


Thanks for …
[Ballot comment]
I am curious about Eric’s 2nd discuss point, hence supporting his discuss on that.

I also support Lars’s and Murray’s comments.


Thanks for working on this specification.
2021-10-05
09 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2021-10-05
09 Barry Leiba Added to session: interim-2021-cbor-18
2021-10-05
09 Éric Vyncke
[Ballot discuss]
Thank you for the work put into this document.

Please find below two blocking DISCUSS points (probably easy to address), some non-blocking COMMENT …
[Ballot discuss]
Thank you for the work put into this document.

Please find below two blocking DISCUSS points (probably easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Barry Leiba for his concise shepherd's write-up but very clear about the WG consensus.

Thank you also to Donald Eastlake for this INT directorate review that I am vastly supporting:
https://mailarchive.ietf.org/arch/msg/int-dir/6Ox8iEBMqXkUoC2aUEF3wi4-c5g/


I hope that this helps to improve the document,

Regards,

-éric


== DISCUSS ==

Generic comment how are link-local address (LLA) with scope encoded ? I would expect CBOR to work also on LLA only networks... At the bare minimum, please state that link-local addresses cannot be encoded with their scope, hence, they cannot represent an interface.

-- Section 3.1.3 --
How can 2 valid link-local addresses (fe80::1%eth0, fe80::1%eth1) can be represented in order to identity two interfaces ?
2021-10-05
09 Éric Vyncke
[Ballot comment]
== COMMENTS ==

I love how your start with IPv6 in section 3 and use the ASCII codes for '6' and '4' ;-) …
[Ballot comment]
== COMMENTS ==

I love how your start with IPv6 in section 3 and use the ASCII codes for '6' and '4' ;-)

-- Section 3.2 --
Is there any reason why part of the IPv6 is in lowercase (as in RFC 5952) and the other part in uppercase ? This is confusing to the reader (even if hexadecimal numbers are obviously case insensitive).

== NITS ==

-- Abstract --
Should CBOR be expanded ?
2021-10-05
09 Éric Vyncke [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke
2021-10-04
09 Roman Danyliw
[Ballot comment]
** Section 7.  Recommend generalizing the text.

OLD
  Identifying which byte sequences in a protocol are addresses may
  allow an attacker …
[Ballot comment]
** 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.


** 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
2021-10-04
09 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2021-10-04
09 Benjamin Kaduk
[Ballot comment]
What should a recipient do if they encounter something in a form that is
expected to include a "natural length" byte string for …
[Ballot comment]
What should a recipient do if they encounter something in a form that is
expected to include a "natural length" byte string for the IP address
family indicated, but the byte string is a different length?  Do we just
need to say that it is "invalid" and thereby invoke the core CBOR rules
that require protocols to specify how their decoders handle invalid
data?  Or is even that implicit from the CDDL?

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.

  This specification defines tags 54 and 52.  These new tags are
  intended to be used in preference to tags 260 and 261.  They provide
  formats for IPv6 and IPv4 addresses, prefixes, and addresses with
  prefixes, achieving an explicit indication of IPv6 or IPv4.  The

I'd suggest saying here that the tag number is the differentiator
between IPv4 and IPv6 -- that could be helpful to know before we go into
the discussion of address/prefix/interface format.  Perhaps "achieving
an explicit indication of IPv6 or IPv4 by the tag number"?

Section 3.1.3

  When applied to an array that starts with a byte string, which stands
  for an IP address, followed by an unsigned integer giving the bit
  length of a prefix built out of the first "length" bits of the
  address, they represent information that is commonly used to specify
  both the network prefix and the IP address of an interface.

We say "full-length" down in §3.2 and 3.3 (and in the CDDL), but should
we perhaps also say here that this byte string need to be the "natural
length" or "full length" for the IP address family in question?

Section 5

  unused_bits = (-prefix_length_in_bits) & 7;
  if (length_in_bytes > 0)
    address_bytes[length_in_bytes - 1] &= (0xFF << unused_bits);

This looks like it's trying to be C, and the XML agrees.  I think it
only has the desired effect when two's-complement representation for
signed integers is used, though (this is not guaranteed by C through at
least C11, though I have not been closely tracking whether the proposal
to make C and C++ two's-complement-only has been adopted), and suggest
reformulating to something like:

  unused_bits = (8 - (prefix_length_in_bits & 7)) % 8;

(This would be DISCUSS level if it was the only specification for the
behavior, but since it is "or simply", it seems more illustrative in
intent.)

NITS

Section 3.2

  54([h'20010db81234DEEDBEEFCAFEFACEFEED', 56])

DEADBEEF (rather than DEEDBEEF) is in somewhat common usage as a pattern
for indicating "tainted" memory in various sanitizer codes...

Section 5

  A particularly paranoid decoder could examine the lower non-relevant
  bits to determine if they are non-zero, and reject the prefix.  This

This would have to be done before the clearing done by the previous
snippet, of course...
2021-10-04
09 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2021-10-04
09 Murray Kucherawy
[Ballot comment]
I concur with Lars' comment.

I'm not sure about the "WRONG" labels.  I suggest including that in prose instead; for instance, something like …
[Ballot comment]
I concur with Lars' comment.

I'm not sure about the "WRONG" labels.  I suggest including that in prose instead; for instance, something like the following:

OLD:

  even though variations like:

  54([44, h'20010db81233'])  WRONG
  54([45, h'20010db8123f'])  WRONG

  would be parsed in the exact same way.

NEW:

  even though variations like:

  54([44, h'20010db81233'])
  54([45, h'20010db8123f'])

  would be parsed in the exact same way; they MUST be
  considered invalid.
2021-10-04
09 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-10-01
09 Robert Wilton
[Ballot comment]
Thanks for defining these, they generally looks useful.

I note that this encoding doesn't cover RFC 4007 scoped IP addressed, e.g., that can …
[Ballot comment]
Thanks for defining these, they generally looks useful.

I note that this encoding doesn't cover RFC 4007 scoped IP addressed, e.g., that can be expressed by YANG's IPv4-address and IPv6-address (RFC 6991).  Is there any thought or plan to support scoped IP addresses, either by extending this tag format, or would these use separate tag numbers if support for them was ever required?  Perhaps the introduction should indicate that scoped IP addresses are out of scope ;-)

Section 3.1.2 and 3.1.3.  Is the array always of length 2 and if so is that worth explicitly stating here?

Section 4, is the last bad example right, i.e., with a prefix length of 45 rather than 44?

  54([45, h'20010db8123f'])  WRONG

Would this not be interpreted as the prefix: "2001:db8:1238::/45"?

I have to confess that I'm not super keen on the ordering of the array arguments defining the meaning of whether it is a prefix or interface definition.  This feels a bit too much like magic for my liking.

Rob
2021-10-01
09 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2021-09-30
09 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-09-30
09 Amanda Baber IANA Experts State changed to Expert Reviews OK
2021-09-30
09 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from No Record
2021-09-30
09 Lars Eggert
[Ballot comment]
Section 1. , paragraph 3, comment:
>    This specification does not
>    deal with 6- or 8-byte Ethernet addresses.

I read …
[Ballot comment]
Section 1. , paragraph 3, comment:
>    This specification does not
>    deal with 6- or 8-byte Ethernet addresses.

I read this and kept wondering about what other Ethernet addresses there are
that I didn't know about... It might be clearer to say something like "does not
include support for Ethernet addresses".

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

These URLs in the document can probably be converted to HTTPS:
* http://www.iana.org/assignments/cbor-tags
2021-09-30
09 Lars Eggert Ballot comment text updated for Lars Eggert
2021-09-28
09 Carlos Bernardos Request for Telechat review by INTDIR is assigned to Donald Eastlake
2021-09-28
09 Carlos Bernardos Request for Telechat review by INTDIR is assigned to Donald Eastlake
2021-09-28
09 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2021-09-28
09 Éric Vyncke Requested Telechat review by INTDIR
2021-09-22
09 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2021-09-22
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-09-22
09 Michael Richardson New version available: draft-ietf-cbor-network-addresses-09.txt
2021-09-22
09 (System) New version approved
2021-09-22
09 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Michael Richardson
2021-09-22
09 Michael Richardson Uploaded new revision
2021-09-22
08 Cindy Morgan Placed on agenda for telechat - 2021-10-07
2021-09-22
08 Francesca Palombini Ballot has been issued
2021-09-22
08 Francesca Palombini [Ballot Position Update] New position, Yes, has been recorded for Francesca Palombini
2021-09-22
08 Francesca Palombini Created "Approve" ballot
2021-09-22
08 Francesca Palombini IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2021-09-22
08 Christian Amsüss Added to session: interim-2021-cbor-17
2021-09-22
08 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2021-09-21
08 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2021-09-21
08 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cbor-network-addresses-08. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cbor-network-addresses-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Concise Binary Object Representation (CBOR) Tags registry located at:

https://www.iana.org/assignments/cbor-tags/

two early registrations will have their references changed to [ RFC-to-be ]. They are:

Tag: 52
Data Item: byte-string or array
Semantics: An IPv4 address or IPv4 prefix

Tag: 54
Data Item: byte-string or array
Semantics: An IPv6 address or IPv6 prefix

Second, also in the Concise Binary Object Representation (CBOR) Tags registry located at:

https://www.iana.org/assignments/cbor-tags/

two existing registrations will be marked "DEPRECATED in favor of 52 and 54." They are:

Tag: 260
Data Item: byte-string
Semantics: Network Address (IPv4 or IPv6 or MAC Address)

Tag: 261
Data Item: byte-string
Semantics: map (IPAddress + Mask Length) Network Address Prefix (IPv4 or IPv6 Address + Mask Length)

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist
2021-09-19
08 Robert Sparks Request for Last Call review by GENART Completed: Ready. Reviewer: Robert Sparks. Sent review to list.
2021-09-10
08 Carlos Bernardos Request for Last Call review by INTDIR is assigned to Zhen Cao
2021-09-10
08 Carlos Bernardos Request for Last Call review by INTDIR is assigned to Zhen Cao
2021-09-09
08 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2021-09-09
08 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2021-09-09
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Daniel Franke
2021-09-09
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Daniel Franke
2021-09-09
08 Éric Vyncke Requested Last Call review by INTDIR
2021-09-08
08 Barry Leiba Request for Last Call review by ARTART is assigned to Alex Gouaillard
2021-09-08
08 Barry Leiba Request for Last Call review by ARTART is assigned to Alex Gouaillard
2021-09-08
08 Cindy Morgan IANA Review state changed to IANA - Review Needed
2021-09-08
08 Cindy Morgan
The following Last Call announcement was sent out (ends 2021-09-22):

From: The IESG
To: IETF-Announce
CC: barryleiba@computer.org, cbor-chairs@ietf.org, cbor@ietf.org, draft-ietf-cbor-network-addresses@ietf.org, francesca.palombini@ericsson.com …
The following Last Call announcement was sent out (ends 2021-09-22):

From: The IESG
To: IETF-Announce
CC: barryleiba@computer.org, cbor-chairs@ietf.org, cbor@ietf.org, draft-ietf-cbor-network-addresses@ietf.org, francesca.palombini@ericsson.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (CBOR tags for IPv4 and IPv6 addresses and prefixes) to Proposed Standard


The IESG has received a request from the Concise Binary Object Representation
Maintenance and Extensions WG (cbor) to consider the following document: -
'CBOR tags for IPv4 and IPv6 addresses and prefixes'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-09-22. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification defines two CBOR Tags to be used with IPv6 and
  IPv4 addresses and prefixes.


  // RFC-EDITOR-please-remove: This work is tracked at
  // https://github.com/cbor-wg/cbor-network-address




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cbor-network-addresses/



No IPR declarations have been submitted directly on this I-D.




2021-09-08
08 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2021-09-08
08 Francesca Palombini Last call was requested
2021-09-08
08 Francesca Palombini Last call announcement was generated
2021-09-08
08 Francesca Palombini Ballot approval text was generated
2021-09-08
08 Francesca Palombini IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2021-09-08
08 Michael Richardson New version available: draft-ietf-cbor-network-addresses-08.txt
2021-09-08
08 (System) New version approved
2021-09-08
08 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Michael Richardson
2021-09-08
08 Michael Richardson Uploaded new revision
2021-09-08
07 Francesca Palombini AD review posted: https://mailarchive.ietf.org/arch/msg/cbor/rOimK4vSkPjPwCUv5BxZA3RX93s/
2021-09-08
07 Francesca Palombini IESG state changed to AD Evaluation::AD Followup from AD Evaluation
2021-09-07
07 (System) Changed action holders to Francesca Palombini (IESG state changed)
2021-09-07
07 Francesca Palombini IESG state changed to AD Evaluation from Publication Requested
2021-09-07
07 Francesca Palombini Ballot writeup was changed
2021-08-03
07 Barry Leiba
1. Summary

This specification defines two new CBOR tags, 54 and 52, which provide formats for IPv6 and IPv4 addresses, respectively.  The new tags are …
1. Summary

This specification defines two new CBOR tags, 54 and 52, which provide formats for IPv6 and IPv4 addresses, respectively.  The new tags are intended to be used in place of the existing 260 and 261 tags, and make a clear distinction between v6 and v4 while also allowing specification of addresses, prefixes, and addresses with prefixes.  These new tags are proposed as standard tags, so the document is a Proposed Standard.

The document shepherd is Barry Leiba; the responsible AD is Francesca Palombini.

2. Review and Consensus

The document is a simple one, and had discussion among a relatively small group of participants.  On request during working group last call we confirmed that the support in the working group is broad, and that the working group as a whole agrees with it.  External reviews have been requested during WGLC and received from OpsDir and IoTDir.  Discussion in general has been largely editorial.  There are broad plans to implement these tags; the desire for the features provided here, noting how 260 and 261 are lacking, was the reason for creating this.

There has been some late discussion to do with zone index, which might continue during IETF-wide last call.  At this time, we don't think changes are needed as a result of that discussion.

3. Intellectual Property

The authors are in full compliance with BCPs 78 and 79, and there have been no IPR issues raised.

4. Other Points

There is nothing else of note here.
2021-08-03
07 Barry Leiba Responsible AD changed to Francesca Palombini
2021-08-03
07 Barry Leiba IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2021-08-03
07 Barry Leiba IESG state changed to Publication Requested from I-D Exists
2021-08-03
07 Barry Leiba IESG process started in state Publication Requested
2021-08-03
07 Barry Leiba Intended Status changed to Proposed Standard from None
2021-08-03
07 Barry Leiba
1. Summary

This specification defines two new CBOR tags, 54 and 52, which provide formats for IPv6 and IPv4 addresses, respectively.  The new tags are …
1. Summary

This specification defines two new CBOR tags, 54 and 52, which provide formats for IPv6 and IPv4 addresses, respectively.  The new tags are intended to be used in place of the existing 260 and 261 tags, and make a clear distinction between v6 and v4 while also allowing specification of addresses, prefixes, and addresses with prefixes.  These new tags are proposed as standard tags, so the document is a Proposed Standard.

The document shepherd is Barry Leiba; the responsible AD is Francesca Palombini.

2. Review and Consensus

The document is a simple one, and had discussion among a relatively small group of participants.  On request during working group last call we confirmed that the support in the working group is broad, and that the working group as a whole agrees with it.  External reviews have been requested during WGLC and received from OpsDir and IoTDir.  Discussion in general has been largely editorial.  There are broad plans to implement these tags; the desire for the features provided here, noting how 260 and 261 are lacking, was the reason for creating this.

There has been some late discussion to do with zone index, which might continue during IETF-wide last call.  At this time, we don't think changes are needed as a result of that discussion.

3. Intellectual Property

The authors are in full compliance with BCPs 78 and 79, and there have been no IPR issues raised.

4. Other Points

There is nothing else of note here.
2021-08-01
07 Michael Richardson New version available: draft-ietf-cbor-network-addresses-07.txt
2021-08-01
07 (System) New version approved
2021-08-01
07 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Michael Richardson
2021-08-01
07 Michael Richardson Uploaded new revision
2021-07-30
06 Christian Amsüss Added to session: IETF-111: cbor  Fri-1430
2021-07-26
06 Barry Leiba
1. Summary

This specification defines two new CBOR tags, 54 and 52, which provide formats for IPv6 and IPv4 addresses, respectively.  The new tags are …
1. Summary

This specification defines two new CBOR tags, 54 and 52, which provide formats for IPv6 and IPv4 addresses, respectively.  The new tags are intended to be used in place of the existing 260 and 261 tags, and make a clear distinction between v6 and v4 while also allowing specification of addresses, prefixes, and addresses with prefixes.  These new tags are proposed as standard tags, so the document is a Proposed Standard.

The document shepherd is Barry Leiba; the responsible AD is Francesca Palombini.

2. Review and Consensus

The document is a simple one, and had discussion among a relatively small group of participants.  On request during working group last call we confirmed that the support in the working group is broad, and that the working group as a whole agrees with it.  External reviews have been requested during WGLC and received from OpsDir and IoTDir.  Discussion in general has been largely editorial.  There are broad plans to implement these tags; the desire for the features provided here, noting how 260 and 261 are lacking, was the reason for creating this.

3. Intellectual Property

The authors are in full compliance with BCPs 78 and 79, and there have been no IPR issues raised.

4. Other Points

There is nothing else of note here.
2021-07-26
06 Barry Leiba Changed consensus to Yes from Unknown
2021-07-26
06 Mohit Sethi Request for Early review by IOTDIR Completed: Ready with Issues. Reviewer: Mohit Sethi. Sent review to list.
2021-07-25
06 Michael Richardson New version available: draft-ietf-cbor-network-addresses-06.txt
2021-07-25
06 (System) New version approved
2021-07-25
06 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Michael Richardson
2021-07-25
06 Michael Richardson Uploaded new revision
2021-07-19
05 Ron Bonica Request for Early review by OPSDIR Completed: Ready. Reviewer: Ron Bonica. Sent review to list.
2021-07-16
05 Samita Chakrabarti Request for Early review by IOTDIR is assigned to Mohit Sethi
2021-07-16
05 Samita Chakrabarti Request for Early review by IOTDIR is assigned to Mohit Sethi
2021-07-16
05 Gunter Van de Velde Request for Early review by OPSDIR is assigned to Ron Bonica
2021-07-16
05 Gunter Van de Velde Request for Early review by OPSDIR is assigned to Ron Bonica
2021-07-16
05 Christian Amsüss IETF WG state changed to In WG Last Call from WG Document
2021-07-16
05 Christian Amsüss Requested Early review by OPSDIR
2021-07-16
05 Christian Amsüss Requested Early review by IOTDIR
2021-07-12
05 Michael Richardson New version available: draft-ietf-cbor-network-addresses-05.txt
2021-07-12
05 (System) New version approved
2021-07-12
05 (System) Request for posting confirmation emailed to previous authors: Michael Richardson , cbor-chairs@ietf.org
2021-07-12
05 Michael Richardson Uploaded new revision
2021-04-21
04 Michael Richardson New version available: draft-ietf-cbor-network-addresses-04.txt
2021-04-21
04 (System) New version approved
2021-04-21
04 (System) Request for posting confirmation emailed to previous authors: Michael Richardson
2021-04-21
04 Michael Richardson Uploaded new revision
2021-03-25
03 Michael Richardson New version available: draft-ietf-cbor-network-addresses-03.txt
2021-03-25
03 (System) New version approved
2021-03-25
03 (System) Request for posting confirmation emailed to previous authors: Michael Richardson
2021-03-25
03 Michael Richardson Uploaded new revision
2021-03-24
02 Barry Leiba Notification list changed to barryleiba@computer.org because the document shepherd was set
2021-03-24
02 Barry Leiba Document shepherd changed to Barry Leiba
2021-03-09
02 Michael Richardson New version available: draft-ietf-cbor-network-addresses-02.txt
2021-03-09
02 (System) New version approved
2021-03-09
02 (System) Request for posting confirmation emailed to previous authors: Michael Richardson
2021-03-09
02 Michael Richardson Uploaded new revision
2021-03-08
01 Christian Amsüss Added to session: IETF-110: cbor  Mon-1530
2021-03-07
01 Michael Richardson New version available: draft-ietf-cbor-network-addresses-01.txt
2021-03-07
01 (System) New version approved
2021-03-07
01 (System) Request for posting confirmation emailed to previous authors: Michael Richardson
2021-03-07
01 Michael Richardson Uploaded new revision
2021-03-07
00 Francesca Palombini This document now replaces draft-richardson-cbor-network-addresses instead of None
2021-03-07
00 Michael Richardson New version available: draft-ietf-cbor-network-addresses-00.txt
2021-03-07
00 (System) WG -00 approved
2021-03-06
00 Michael Richardson Set submitter to "Michael Richardson ", replaces to (none) and sent approval email to group chairs: cbor-chairs@ietf.org
2021-03-06
00 Michael Richardson Uploaded new revision