Subject: [Cbor] Éric Vyncke's Discuss on draft-ietf-cbor-network-addresses-09: (with DISCUSS and COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 05 Oct 2021 06:34:16 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-cbor-network-addresses-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cbor-network-addresses/

----------------------------------------------------------------------
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 ?

----------------------------------------------------------------------
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 ?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Oct 2021 12:59:19 -0400

{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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Oct 2021 13:15:44 -0400

> https://mailarchive.ietf.org/arch/msg/int-dir/6Ox8iEBMqXkUoC2aUEF3wi4-c5g/

I have added one oxford comma, I didn't find more missing.

I have adopted Donald's suggested text.
I have removed "Note that" as he suggested.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Oct 2021 14:55:18 -0400

Captured as issue:
   https://github.com/cbor-wg/cbor-network-address/issues/12

    > represented in order to identity two interfaces ?

There are three kinds of things encoded:
      a) addresses.
      b) prefixes
      c) interface definitions

For (b) and (c), we could easily entertain (and did we discuss this in the
thread that was CC'ed to 6man?) adding a third element to the array to store
the interface ID.
For (a), I'm not sure what we can do to add the interface ID, but see below.

That's kinda the easy part.
The hard part is deciding how to encode the scope.
The simplest is as an integer, being the ifindex.

CBOR makes that easy and efficient, and many systems don't have more than 24
interfaces.  However, on systems where interfaces come/go a lot, the ifindex
often increments anyway.  Using the ifindex is probably clearer on most any
system than a string which can change, but it does change from one boot to
another.
While the ifindex is system specific and has no outside meaning, the purposes
where I imagine this being used would be in some system specific container.
(My use case, which drove me to do this, actually probably needed scope-id)

One way to do (a) could be to append to the IPv6 string.
Another way would be not to bother, to always use the interface definition
when a IPv6-LL is needed.  Whether the length is 0, 128, or the actual
interface prefix (probably 64) is something we could specify.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 5 Oct 2021 21:14:05 +0000

Michael

The problem is indeed solvable.

My own take would be not to use ifIndex (for the reasons you just explained) also it could be confusing with another encoding as both (length & ifindex) are uint...

As I wrote in my ballot, an alternative (not so nice though) would be to clearly state that the encoding is not applicable to LLA + scope

-éric

On 05/10/2021, 20:55, "Michael Richardson" <[email-masked]> wrote:

    Captured as issue:

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 5 Oct 2021 23:42:02 +0200

> The problem is indeed solvable.

I think the perception we arrived at when we did explore solving it was that the ifindex/ifname issue was too much in flux to commit to either.
YANG ietf-inet-types can simply ignore that problem because YANG is all textual anyway:

(%[\p{N}\p{L}]+)?

(N is numbers, L is letters, so 03Å and 17 and FARP and 𝔈𝔗ℌ0 are all great zone identifiers — you don’t even get to know whether 17 is an ifname or an ifindex).

> My own take would be not to use ifIndex (for the reasons you just explained) also it could be confusing with another encoding as both (length & ifindex) are uint...

That is more of a secondary concern then — we’d first like to get the information model level data types right.

> As I wrote in my ballot, an alternative (not so nice though) would be to clearly state that the encoding is not applicable to LLA + scope

Tags are cheap enough.
52 and 54 are the CBOR “no-zone” equivalents then, and we can always define tags for potentially zoned addresses once the ifindex/ifname issue converges.

(I do not have a *strong* opinion that this is the right decision, but I think the reasons we arrived where we are, do make sense.)

Grüße, Carsten

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 5 Oct 2021 18:01:56 -0400

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
 [email-masked]

---

From: Erik Kline <[email-masked]>
Date: Tue, 5 Oct 2021 15:57:17 -0700

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?  ;-)

---

From: Erik Kline <[email-masked]>
Date: Tue, 5 Oct 2021 16:59:41 -0700

> thread that was CC'ed to 6man?)
>

Mostly for Eric's benefit:

https://mailarchive.ietf.org/arch/msg/ipv6/qp_7ODeUY9SrT9cqFyYL6kybCsw/  is
where I remember having left off

(and the mailarchive shows the thread path of progression)

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 6 Oct 2021 13:44:45 +1300

> system than a string which can change, but it does change from one boot 
to

Correct, but the name can also change (I forget the magic command on Linux,
but it exists). In socket calls such as connect() you need the interface
index, and the conversion from interface id to interface index is a bit
system-dependent but typically involves getaddrinfo(). The only safe
assumption is that they're both dynamic, but which you need depends on
the exact use case.

I suggest that we should be able to support both formats. Since CBOR is typed,
that's easy enough.

    Brian

> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 5 Oct 2021 21:26:49 -0400

Hi,

> <https://datatracker.ietf.org/doc/html/rfc7043#section-7> for the new

<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

On Tue, Oct 5, 2021 at 3:02 PM Donald Eastlake <[email-masked]> wrote:
>>> Opened as issue:
>>> https://github.com/cbor-wg/cbor-network-address/issues/9
>>>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Oct 2021 10:25:18 -0400

> Perhaps rfc7042bis should specify a CBOR tag for MAC addresses. I'd be

I think that this is the best result.

---

From: Thiago Macieira <[email-masked]>
Date: Wed, 6 Oct 2021 08:06:07 -0700

> assumption is that they're both dynamic, but which you need depends on

Actually, the front-end API is if_nametoindex(). The low-level one involves 
either a SIOCGIFINDEX or open a netlink socket and querying with RTM_GETLINK.

> I suggest that we should be able to support both formats. Since CBOR is
> typed, that's easy enough.

Agreed. That avoid a conversion that might need to be undone on the other 
side. The other side may want to display something to the user and therefore 
may want to have the "nice" interface name.

Not that "wlp0s20f3" is nice, for me. I've had this laptop for 3 months and 
have yet to memorise that.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Oct 2021 12:18:58 -0400

Hi, at the CBOR WG meeting this morning, support for IPv6 LL scopes
was the major topic.

We added an optional third parameter to the interface definition,
and made it valid to specify the interface prefix length as "false"

I hope that I got the CDDL right:
  https://github.com/cbor-wg/cbor-network-address/blob/main/cbor-network-addresses.mkd#cddl

Examples:
  https://github.com/cbor-wg/cbor-network-address/blob/main/cbor-network-addresses.mkd#ipv6

We also agreed to lowercase all HEX, and to leave Ethernet tags for Donald's
rfc7042bis.  (despite that being informational and a possible downref issue)

We agreed that Invalid CBOR is... invalid CBOR, and that the CDDL gives the
details for the limits.

I have posted a revision -10, which I hope satisfies all of the DISCUSS and
comments:

  https://www.ietf.org/rfcdiff?url1=draft-ietf-cbor-network-addresses-09&url2=draft-ietf-cbor-network-addresses-10

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 7 Oct 2021 09:42:15 +1300

Looks good to me.

(I'd be inclined to add a note that the interface id/index has no significance outside the host where it is defined and cite RFC4007, but it's not 
essential.)

Regards
   Brian

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 6 Oct 2021 23:15:04 +0200

> Hi, at the CBOR WG meeting this morning, support for IPv6 LL scopes

YANG ietf-inet-types has zones for IPv4.
Shouldn’t we, too?

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Oct 2021 17:53:57 -0400

Brian E Carpenter <[email-masked]> wrote:
    > (I'd be inclined to add a note that the interface id/index has no
    > significance outside the host where it is defined and cite RFC4007, but
    > it's not

I was struggling to find the right RFC that defines zone/scope, and 4007 is a
good choice.

https://github.com/cbor-wg/cbor-network-address/commit/922fc54e6684d6d691c9dd3fd88a77ec16cf1126#diff-ebc4094e1911b5707c22b5f72c92c35363efd187de5e27c426d9a3cf37d64288

 > As explained in {{RFC4007}} the zone identifiers are strictly local to the
 > node. They are useful for communications within a node about connected
 > addresses (for instance, where a link-local peer is discovered by one
 > daemon, and another daemon needs to be informed).
 > They may also have utility in some management protocols.

(I decided to be vague about which management protocols, because I don't
know, and RESTCONF and SNMP already have solutions. )

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Oct 2021 17:55:46 -0400

> YANG ietf-inet-types has zones for IPv4.

Are there any OSes and Applications that really know how to deal with having
IPv4-LL addresses on multiple interfaces?  And didn't IPv4 die awhile back?

If you really think we should do this for IPv4, I don't really object.
I just don't know what RFCs to cite.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 7 Oct 2021 11:44:48 +1300

> I just don't know what RFCs to cite.

That's probably because there are none. As far as I know, there is no
"Scoped architecture for IPv4" RFC. I don't know why there is YANG support.

Michael's text citing RFC4007 looks good to me.

    Brian

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 7 Oct 2021 03:40:24 +0200

> "Scoped architecture for IPv4" RFC. I don't know why there is YANG support.

Zones are this gift that keeps on giving.

If we are doing zones, we need to do them like YANG.
I would have a strong objection against including them but then doing them differently.
Maybe we should simply reference RFC 6991 as well.

Jürgen:  Do you remember why ipv4-address has a zone ID (called “zone index”)?

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 7 Oct 2021 04:13:40 +0200

On 7. Oct 2021, at 03:58, Erik Kline <[email-masked]> wrote:
> 
> To my knowledge the closest such thing would be RFC 3927.
> 
> I've never seen anything like an extension of sockaddr_in to add the equivalent of sin6_scope_id, though it's not hard to imagine what would be required to make some "sin_scope_id" thing work.

Interesting.  While IPV6_MULTICAST_IF is defined in RFC 3493, the RFCs seem to be silent about IP_MULTICAST_IF.
(This would be another case where an IP address would be combined with an ifindex, even if that is not called a “zone ID” there.)

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 7 Oct 2021 16:31:14 +1300

On 07-Oct-21 15:13, Carsten Bormann wrote:
>> I've never seen anything like an extension of sockaddr_in to add the equivalent of sin6_scope_id, though it's not hard to imagine what would be 
required to make some "sin_scope_id" thing work.
> (This would be another case where an IP address would be combined with an ifindex, even if that is not called a “zone ID” there.)

Formally, IPv4 addresses are assigned to a host, but IPv6 addresses are assigned to an interface. And consequently, IPv6 has a scoped address architecture and a scoped multicast address architecture. I think it's normal 
that these are reflected in APIs and absent in IPv4 APIs.

I think the whole question of multicast addresses needs careful analysis, 
so personally I'd defer it for now.

   Brian

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 7 Oct 2021 08:43:38 +0200

> Jürgen:  Do you remember why ipv4-address has a zone ID (called “zone index”)?

The YANG definitions were derived from the SNMP definitions. I think
the first RFC having support for zoned IPv4 addresses in the network
management world was RFC 2851 (published June 2000). I vaguely recall
that we had several side meetings during the draft writing stage where
people pointed to other work (that may have led to things like RFC
3927 later on) and/or they pointed out that the need to disambiguate
IP addresses also exists in the IPv4 world. I think people also
pointed to routers running multiple links using the same non-global
(e.g., private) address spaces.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 7 Oct 2021 11:41:52 +0200

Thank you!

I can’t find zones in 2851, but InetAddressIPv4z is in 3291 (of 2002 vintage, which also mentions InetAddressIPv6z in the Section 9, Changes) and 4001 (which we could reference alongside RFC 6991).  SNMP InetAddressIPv4z (or InetAddressIPv6z) only supports a numeric zone index, which is a 32-bit (Unsigned32 as per RFC4001 InetZoneIndex, which is mentioned in the RFC 4001 Section 8, Changes) number, but I think the generality of RFC 6991 (and the symmetry of the IP versions) wins here.

(RFC 3291 mentions v4-mapped IPv6 addresses as a source of zoned IPv4 addresses.  Thinking about it, that’s exactly where I have used them.)

Grüße, Carsten

> On 2021-10-07, at 08:43, Jürgen Schönwälder <[email-masked]> wrote:
>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 7 Oct 2021 10:00:15 +0000

Hi Michael,

A couple of comments on -10

In section 2:
- It still references a two element array for IP address and prefix, but presumably it is a 2 or 3 element array.
- How often are zones actually used?  Would it not just be simpler to always use a string interface identifier?
- Is "false" for a prefix length a better choice than using either -1 or null?

I still think the example in section 4 probably needs fixing:

   52([44, h'20010db81230'])

^- Should this be 54 rather than 52?

   even though variations like:

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

^- Should this be 44 rather than 45?  Because otherwise it looks like it would parse to a different prefix.

Thanks,
Rob

-----Original Message-----
From: iesg <[email-masked]> On Behalf Of Michael Richardson
Sent: 06 October 2021 17:19
To: Eric Vyncke (evyncke) <[email-masked]>; [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Brian E Carpenter <[email-masked]>
Subject: Re: Re: [Cbor] Supporting IPv6 Link-Local with scope (was Re: Éric Vyncke's Discuss on draft-ietf-cbor-network-addresses-09: (with DISCUSS and COMMENT))

Examples:

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 7 Oct 2021 12:38:38 +0200

Hi Rob,

thank you very much for the quick feedback!

I addressed the comments together with the IPv4 zone identifier discussion in
https://github.com/cbor-wg/cbor-network-address/pull/13

> On 2021-10-07, at 12:00, Rob Wilton (rwilton) <rwilton=[email-masked]> wrote:
> 
> Hi Michael,
> 

I added text that explains that case.

> - How often are zones actually used?  Would it not just be simpler to always use a string interface identifier?

Ifindex and Ifname are two different concepts that should not be mixed.
The textual nature of RFC 6991 makes it seem natural to always use a textual representation for the Ifindex; this is not the case here.

> - Is "false" for a prefix length a better choice than using either -1 or null?

false is not better than null.
Actually, as this is representing what would be an optional element in an array, conventional CBOR idioms would call for null, but that is a matter of style.
I switched to null in the PR because you brought it up, but don’t have a strong opinion.

false/null definitely is better than -1.

> ^- Should this be 54 rather than 52?

Fixed.

> ^- Should this be 44 rather than 45?  Because otherwise it looks like it would parse to a different prefix.

The example itself is good but the text around it doesn’t fit.  
Changed to 44.

Grüße, Carsten

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 7 Oct 2021 12:57:53 +0200

Yes, there are two things, recognizing that there is a need to
disambiguate addresses and then what you choose to disambiguate
them. Back in SNMP times, everything was commonly identified by
numbers. When we moved to YANG, we started to prefer using names as
there was a push to move closer to what people use on their CLIs
instead of what a kernel may be using internally. (The ifTable was
indexed by the numeric ifIndex, the YANG interfaces list is keyed by
interface names.) I guess as part of this transition, we moved from
using numeric zone indexes (that usually are simply ifIndex values) to
zone names (that are usually interface names).

/js

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 7 Oct 2021 11:00:04 +0000

Hi Carsten,

Snipped most of it, just one comment inline ...

> From: Carsten Bormann <[email-masked]>
> Sent: 07 October 2021 11:39
> To: Rob Wilton (rwilton) <[email-masked]>
<snipped> 
> The textual nature of RFC 6991 makes it seem natural to always use a textual
> representation for the Ifindex; this is not the case here.

Okay, so thinking about converting from YANG to this CBOR representation, then would the expectation be that it is okay to use a string that represents an integer?  And is that logically the same or different?  Or would the expectation be that the zone string should be converted (normalized) to an integer if it can be?  Does any of this need to be specified?

Thanks,
Rob

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 7 Oct 2021 13:50:00 +0200

On 2021-10-07, at 13:00, Rob Wilton (rwilton) <[email-masked]> wrote:
> Okay, so thinking about converting from YANG to this CBOR representation, then would the expectation be that it is okay to use a string that represents an integer?  

If I needed to write a converter from YANG ietf-inet-types, I would match on digits only and then create an unsigned integer, and use a text string otherwise.

> And is that logically the same or different?  Or would the expectation be that the zone string should be converted (normalized) to an integer
> if it can be?  

You’d need to be on the system in question, and the conversion result might be rather ephemeral...

> Does any of this need to be specified?

Depends on where the conversion from YANG ietf-inet-types to CBOR 52/54 should be specified.  With zero operational experience, that would seem a bit more speculative to me than I like.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 7 Oct 2021 03:38:57 +0200

Grüße, Carsten

---

From: Erik Kline <[email-masked]>
Date: Wed, 6 Oct 2021 18:58:43 -0700

I've never seen anything like an extension of sockaddr_in to add the
equivalent of sin6_scope_id, though it's not hard to imagine what would be
required to make some "sin_scope_id" thing work.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Oct 2021 10:04:41 -0400

Let's try to keep the distribution list trimmed so these messages
don't keep going into moderation.  In this message I've eliminated the
people who are subscribed to the CBOR list.  As it's also going to the
IESG, we could remove the two ADs from the distribution as well,
though I'm leaving them on for now, thinking that having them on
directly might make it easier for them.

Thanks,
Barry

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Oct 2021 14:31:54 -0400

Rob Wilton (rwilton) <[email-masked]> wrote:
    > - How often are zones actually used?  Would it not just be simpler to
    > always use a string interface identifier?

I don't think it would to always do that.
My use case is that I have a (GRASP) daemon that discovers peers on
particular interfaces, and it knows those interfaces by ifindex.
It then tells another daemon (IKEv2) about those peers.
If it did it by name, then that just forces both ends to do the
name<->ifindex mapping for no gain.  I could live with that though.

    > - Is "false" for a prefix length a better choice than using either -1 or null?

We've gone for null.

    > it would parse to a different prefix.

We've fixed it.
I had some other wrong case in mind when I wrote 45 :-)

---

From: Thiago Macieira <[email-masked]>
Date: Thu, 07 Oct 2021 11:42:09 -0700

>     > - Is "false" for a prefix length a better choice than using either -1

false, null, 0, -1 and an empty string all have the same length and meaning 
for interfaces indices and names. Null makes the purpose clear (information 
absent) and the distinction between that and 0 might be important somewhere.

Like C++ std::optional<PointerType>: a disengaged optional is different from a 
an engaged optional containing a null pointer. One of those may convey "an 
error occurred" whereas the other says "success, information not applicable". 
Though I'd suggest using undefined for errors in CBOR, instead of null. So 
maybe a null interface is "valid, but missing", an undefined interface is 
"invalid, error" and a zero/empty interface is "not applicable in this 
context" (such as all non-link-local cases).

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 8 Oct 2021 09:15:11 +1300

> (e.g., private) address spaces.

Unfortunately that never seems to have led to an equivalent of
RFC4007 or, as far as I can tell, a systematic definition of
interface id or interface index for IPv4, or to any recognition
of all this in the POSIX API. There is just a rather sad statement
in RFC3927: "At the time of this writing, there is no silver bullet
which solves these problems in all cases, in a general way."

The fact that it's covered, in a certain sense, by MIB modules and
YANG modules, doesn't help with this definitional problem. For
the present draft, that is OK, but I think there is a deeper
problem. Probably, we just have to accept that it isn't worth
doing anything about it for the legacy version of IP.

I'm happy with the proposed changes to the draft.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 8 Oct 2021 09:18:38 +1300

> I don't think it would to always do that.

Definitely not. It depends on the application context, and as noted
earlier in the thread, translation between identifier and index is
system dependent, and both can change dynamically.

Also the index is fewer bytes, and in constrained nodes that
might matter.

   Brian