Subject: [Anima] RFC8992bis? [was RFC 9164 on Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes]

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Dec 2021 16:30:39 +1300

So, congratulations on this RFC. Should ANIMA consider an incompatible update to RFC8992 to use these new CBOR tags instead of the existing ad hoc solution?

I don't think we have an installed base to worry about, and the difference for an implementor is not very big.

Regards
    Brian

On 14-Dec-21 12:36, [email-masked] wrote:
> A new Request for Comments is now available in online RFC libraries.
> 
>          
>          RFC 9164
> 
>          Title:      Concise Binary Object Representation (CBOR)
>                      Tags for IPv4 and IPv6 Addresses
>                      and Prefixes
>          Author:     M. Richardson,
>                      C. Bormann
>          Status:     Standards Track
>          Stream:     IETF
>          Date:       December 2021
>          Mailbox:    [email-masked],
>                      [email-masked]
>          Pages:      10
>          Updates/Obsoletes/SeeAlso:   None
> 
>          I-D Tag:    draft-ietf-cbor-network-addresses-13.txt
> 
>          URL:        https://www.rfc-editor.org/info/rfc9164
> 
>          DOI:        10.17487/RFC9164
> 
> This specification defines two Concise Binary Object Representation
> (CBOR) tags for use with IPv6 and IPv4 addresses and prefixes.
> 
> This document is a product of the Concise Binary Object Representation Maintenance and Extensions Working Group of the IETF.
> 
> This is now a Proposed Standard.
> 
> STANDARDS TRACK: This document specifies an Internet Standards Track
> protocol for the Internet community, and requests discussion and suggestions
> for improvements.  Please refer to the current edition of the Official
> Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
> standardization state and status of this protocol.  Distribution of this
> memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>    https://www.ietf.org/mailman/listinfo/ietf-announce
>    https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [email-masked].  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Dec 2021 13:43:05 -0500

Brian E Carpenter <[email-masked]> wrote:
    > So, congratulations on this RFC. Should ANIMA consider an incompatible
    > update to RFC8992 to use these new CBOR tags instead of the existing ad
    > hoc solution?

Maybe. I'm not sure.
I will see about adapting my implementation and post a further opinion.

    > I don't think we have an installed base to worry about, and the
    > difference for an implementor is not very big.

Yes, that's true.  On the other hand, I'd hardly like to encourage IPv4 ACPs.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Dec 2021 08:47:56 +1300

> Yes, that's true.  On the other hand, I'd hardly like to encourage IPv4 
ACPs.

I said 8992 and I think you saw 8994...

I agree with you of course, but I wrote 8992 and I think you saw 8994...

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Dec 2021 15:28:52 -0500

> I said 8992 and I think you saw 8994...

Yeah, I get that :-)

But, no point in advertising in GRASP (over an ACP) an objective that only be
satisfied by going to the dataplane to do IPv4.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 16 Dec 2021 23:32:34 +0100

> satisfied by going to the dataplane to do IPv4.

ASA would use the ACP (IPv6) to coordinate amongst each other for
some autonomic function, BUT: The objective data/parameters they
exchange would often be about their nodes data-plane addresses, which
will often be IPv4. For example i create an "Auto-IP-Multicast AF",
then the ASA would announce their data-plane IPv4 addresses for e.g.:
RP election or the like.

Aka: Unless i misunderstand something i see no concern about
creating trouble for our "IPv6-is-enough" ACP strategy.

Cheers
     Toerless

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Dec 2021 16:42:54 -0500

Toerless Eckert <[email-masked]> wrote:
    >> But, no point in advertising in GRASP (over an ACP) an objective that
    >> only be satisfied by going to the dataplane to do IPv4.

    > ASA would use the ACP (IPv6) to coordinate amongst each other for some
    > autonomic function, BUT: The objective data/parameters they exchange
    > would often be about their nodes data-plane addresses, which will often
    > be IPv4. For example i create an "Auto-IP-Multicast AF", then the ASA
    > would announce their data-plane IPv4 addresses for e.g.: RP election or
    > the like.

yes, but that would be in the negotiation about that ASA (which is new work
at this point), and in which one could use RFC9164.

What I understand is Brian suggesting that we change RFC8992, section 5.1,
5.2, so that instead of:

     prefval /= pref6val
     pref6val = [version6, length, ?prefix]
     version6 = 6
     length = 0..128             ; requested or offered prefix length
     prefix = bytes .size 16     ; offered prefix in binary format

     prefval /= pref4val
     pref4val = [version4, length4, ?prefix4]
     version4 = 4
     length4 = 0..32             ; requested or offered prefix length
     prefix4 = bytes .size 4     ; offered prefix in binary format

we'd plug in RFC9164.
(Section 6.1 could also be revised)

As far as I can see, we could trivially augment prefval with a tagged item
there.  Is it worth doing? I don't think so.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Dec 2021 11:04:38 +1300

> there.  Is it worth doing? I don't think so.

The only argument I have is that once the new tags are supported in the
popular CBOR libraries, we'd very slightly reduce the work involved
in implementing RFC8992. But looking at my demo code, it's a negligible
change. I agree that it isn't worth updating the RFC for this. Unless
anyone disagrees, I think the discussion's over.

    Brian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Dec 2021 23:20:17 +0100

On 17. Dec 2021, at 23:04, Brian E Carpenter <[email-masked]> wrote:
> 
> I agree that it isn't worth updating the RFC for this.

+1

Grüße, Carsten