Subject: Re: [CDNi] New Internet Draft: draft-sopher-cdni-footprint-types-extensions

From: Guillaume Bichot <[email-masked]>
Date: Sun, 10 Jan 2021 22:20:28 +0000

Hi Sanjay & Nir.

Here is the  statement from 8008 (Appendix B) : Multiple footprint constraints are additive: the advertisement of different footprint types narrows the dCDN's candidacy cumulatively.

Frankly, this is very strange that the statement is almost hidden in a kind of annex  whereas it could have been located in section 5 in a proper dedicated section.

Your proposal solves the issue but not completely. I guess nothing prevent me to add several footprint constraints of the same type like the example below. Strictly speaking, if I captured well that statement, we should end up with an empty list as well.

{

     "capabilities": [

       {

         "capability-type": <CDNI capability object type>,

         "capability-value": <CDNI capability object>,

         },

         "footprints": [

             {

                 "footprint-type": "ipv4cidr",

                 "footprint-value": ["192.0.20/24"].

             },

             {

                 "footprint-type": "ipv4cidr",

                 "footprint-value": [["192.0.21/24"]

             }

         ]

       }

     ]

   }

I have another proposal  that is the following: instead of creating a new footprint type that requires a change in RFC8006 as well, why not just changing that statement that looks strange and almost faulty.

-remove that faulty statement in Appendix B.

- create a new section 5.x about "footprints" and add a new statement (or just add that new statement in Appendix B) like the following:

"Several footprint constraints can be given of either the same type or not.   The uCDN MUST consider the resulting footprint as a set of geographical areas constrained with a set of IP address ranges if any. If several geographical areas overlap then the coverage zone corresponds to the cumulative areas."

Examples

-          E1: a set of address ranges

"ipv4cidr", ["192.0.2.0/24", "192.0.2.1/24"]

"ipv4cidr", ["192.0.2.2/28"]

"ipv6cidr", ["2001:db8::/32"]

-          E2: a set of geographical areas
"iso3166code", ["ca", us-ny]

-          E3: a mixed of geographical areas and address ranges

"ipv4cidr", ["192.0.2.0/24"]

"ipv6cidr", ["2001:db8::/32"]

-          "iso3166code", ["ca", "us-ny"]

Guillaume

Guillaume BICHOT, Principal Engineer, Head of Exploration
+33 (0) 6 8559 7666 | [email-masked]<mailto:[email-masked]>

From: CDNi [mailto:[email-masked]] On Behalf Of Nir Sopher
Sent: Wednesday, December 23, 2020 6:19 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [E] [CDNi] New Internet Draft: draft-sopher-cdni-footprint-types-extensions

Hi,

We have submitted draft-sopher-cdni-footprint-types-extensions<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dsopher-2Dcdni-2Dfootprint-2Dtypes-2Dextensions_%26d%3DDwMFaQ%26c%3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ%26r%3DXniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM%26m%3DTs5uj_nZmoHgi7pPldjWKsDPgmeeiO_RkotsI8zZD-E%26s%3DoWZZ4TjWJsq7Ao899RmyOUwUgAjNYeVlksfkKAy-UeA%26e%3D&data=04%7C01%7Cguillaume.bichot%40broadpeak.tv%7Cf6b67a86cc4b44ff6b7a08d8a83b82a1%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637444320869999346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YxIzX3bst5GAicrOxFI%2BqfRZYO65%2Fwh07pDTwoYrrJg%3D&reserved=0> that extends RFCs 8006/8008 in order to address the following issue:

  *   Sections 4.3.5 and 4.3.6 of [RFC8006] specify the "IPv4CIDR" and  "IPv6CIDR" footprint types, respectively, for listing IP addresses blocks.  Using Footprint Objects of these types, one can define an FCI Capability Advertisement Object footprint constraints that match IPv4 or IPv6 clients. Also as described in section 5 of RFC 8008, the FCI Capability Advertisement Object includes an array of such CDNI Footprint Objects. The array of Footprint Objects has a "narrowing" semantic that prevents the usage of IPv4/IPv6 objects together in order to create a footprint constraint that matches IPv4 clients together with IPv6 clients.

In the submitted draft:

  1.  We add a new usecase of dCDN advertising a footprint that consists of both IPv4 and IPv6 client addresses, by defining a new "IPv4v6CIDR" Footprint Type.
  2.  We also add support for ISO3166Code Footprint Type, based on ISO 3166 country codes and regions definition. This Footprint Type allows the dCDN to advertise a footprint based on a specific region, for example a state in the USA.
We would highly appreciate it if folks can review and provide any feedback.

Thanks and Happy Holidays,
Sanjay & Nir

---

From: Kevin Ma <[email-masked]>
Date: Mon, 11 Jan 2021 00:56:16 -0500

Hi All,

  It's been a while since we had the FCI debates, and FCI has a rather
complex history, so I've had to refresh my memory.

  wrt the text in question: "Multiple footprint constraints are additive:
the advertisement of different footprint types narrows the dCDN's candidacy
cumulatively." I believe that statement was referring to if multiple FCI
messages were sent for the same capability but the messages had different
footprints in them; I do not believe it was intended to apply to multiple
footprints in the same message.  (I believe it stemmed from a protocol
implementation question for how to override footprints and how to deal with
footprints in sequential messages, which I had addressed in my original
capabilities protocol draft:
https://tools.ietf.org/html/draft-ma-cdni-capabilities-04#section-2 and
https://tools.ietf.org/html/draft-ma-cdni-capabilities-04#section-3.2 .)

  In addition, I don't know that we should give any normative weight to a
non-normative statement in an appendix.  As the draft points out (
https://tools.ietf.org/html/draft-sopher-cdni-footprint-types-extensions-01#section-2.1
), applying the statement to the list of footprints in a single message
produces an absurd result (i.e., disjoint footprints produce an empty set
of footprints), and that was certainly not the intention (which I think we
can infer from the prevention of such a result in the protocol drafts).

> Frankly, this is very strange that the statement is almost hidden in a
kind of annex  whereas it could have been located in section 5 in a proper
dedicated section.

  Coming out of IETF 90 and 91, we had decided to focus the FCI semantics
draft on just the information that needed to be advertised and separate out
the protocol specifications (see:
https://mailarchive.ietf.org/arch/msg/cdni/3GVjUbBNsf2gV8fQUhcVBRID_mU/ ).
All of the less relevant material was moved to appendices (per:
https://mailarchive.ietf.org/arch/msg/cdni/2gLvfnlbpJjIo57bER72kIiSZsk/ ).
In hindsight we probably could've done more to clean up the appendices, but
as is always the case, we did not have the benefit of hindsight at the
time.  The decision was made to rely on ALTO as a transport protocol, which
defines its own footprint type and enforcement rules (see:
https://tools.ietf.org/html/draft-ietf-alto-cdni-request-routing-alto-14#section-4.1
).

  We probably also could have done more to specify the interpretation of
the footprint list, but I think that was just delegated to the protocol
specs.  At the time, there was contentious debate between advertising of
footprints vs advertising of capabilities (thus:
https://tools.ietf.org/html/rfc8008#section-3 ), and our focus was
clarifying the advertisement of capabilities with footprint restrictions
and completing the semantics draft so we could move forward with the
protocol draft(s).

  If folks feel strongly about the appendix being confusing, we could
consider filing an errata?

Sanjay/Nir,

  If we disregard the statement in the appendix and assume that within a
single message, multiple footprint types are allowed and are considered as
a set, does that negate the need for the proposed ipv4v6cidr footprint type?

  wrt the iso3166code footprint type, I don't see any issue with it if
folks feel it would be useful.

thanx!

--  Kevin J. Ma

On Sun, Jan 10, 2021 at 5:54 PM Guillaume Bichot <
[email-masked]> wrote:

> - create a new section 5.x about “footprints” and add a new statement (or just add that new statement in Appendix B) like the following:
>
> ”Several footprint constraints can be given of either the same type or not.   The uCDN MUST consider the resulting footprint as a set of geographical areas constrained with a set of IP address ranges if any. If several geographical areas overlap then the coverage zone corresponds to the cumulative areas.”
>
>
>
> Examples
>
> "ipv4cidr", ["192.0.2.0/24", “192.0.2.1/24”]
>
> “ipv4cidr”, [“192.0.2.2/28”]
>
> -          "iso3166code", ["ca", “us-ny”]
>
>
>
> Guillaume
>
>
>
> *Guillaume BICHOT, **Principal Engineer, Head of Exploration*
>
> +33 (0) 6 8559 7666 | [email-masked]
>
>
>
>
>
> *From:* CDNi [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Nir Sopher
> *Sent:* Wednesday, December 23, 2020 6:19 PM
> *To:* [email-masked]
> *Subject:* [E] [CDNi] New Internet Draft:
> draft-sopher-cdni-footprint-types-extensions
>
>
>
> Hi,
>
>
>
> We have submitted draft-sopher-cdni-footprint-types-extensions
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dsopher-2Dcdni-2Dfootprint-2Dtypes-2Dextensions_%26d%3DDwMFaQ%26c%3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ%26r%3DXniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM%26m%3DTs5uj_nZmoHgi7pPldjWKsDPgmeeiO_RkotsI8zZD-E%26s%3DoWZZ4TjWJsq7Ao899RmyOUwUgAjNYeVlksfkKAy-UeA%26e%3D&data=04%7C01%7Cguillaume.bichot%40broadpeak.tv%7Cf6b67a86cc4b44ff6b7a08d8a83b82a1%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637444320869999346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YxIzX3bst5GAicrOxFI%2BqfRZYO65%2Fwh07pDTwoYrrJg%3D&reserved=0>
> that extends RFCs 8006/8008 in order to address the following issue:
>
>    - Sections 4.3.5 and 4.3.6 of [RFC8006] specify the "IPv4CIDR" and
>    "IPv6CIDR" footprint types, respectively, for listing IP addresses blocks.
>    Using Footprint Objects of these types, one can define an FCI Capability
>    Advertisement Object footprint constraints that match IPv4 or IPv6 clients.
>    Also as described in section 5 of RFC 8008, the FCI
>    Capability Advertisement Object includes an array of such CDNI Footprint
>    Objects. The array of Footprint Objects has a "narrowing" semantic that
>    prevents the usage of IPv4/IPv6 objects together in order to create a
>    footprint constraint that matches IPv4 clients together with IPv6 clients.
>
>
>
> In the submitted draft:
>
>    1. We add a new usecase of dCDN advertising a footprint that consists
>    of both IPv4 and IPv6 client addresses, by defining a new "IPv4v6CIDR"
>    Footprint Type.
>    2. We also add support for ISO3166Code Footprint Type, based on ISO
>    3166 country codes and regions definition. This Footprint Type allows the
>    dCDN to advertise a footprint based on a specific region, for example a
>    state in the USA.
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>

---

From: Nir Sopher <[email-masked]>
Date: Mon, 11 Jan 2021 18:45:33 +0200

Thanks Guillaume and Kevin,

Indeed, disregarding the statement in the appendix would negate the need
for the ipv4v6cidr.
However, IIUC, this would weaken the protocol:
Take for example an integration where we would like the footprint to cover
only clients within a Europe wide spread ASN, but only in Belgium, or only
the NY clients of a US-wide ASN. The protocol when disregarding the
"narrowing semantics" statement would not be able to specify it (while in
the original semantics it is definable).

One can argue we need to be able to create some boolean expression. ORing
and ANDing footprints.
I think a better approach (Guillaume, it might be the direction you were
pointing at), is to define now a "footprint object class", grouping the
"footprint object types"

   1. Footprint Class: ip
   Grouped footprint-types:
      1. ipv4cidr
      2. ipv6cidr
      3. asn
   2. Footprint Class: geo
   Grouped footprint-types:
      1. countrycode
      2. iso3166code

When a footprint objects list is composed from multiple footprint-object
classes, we should first merge objects from the same class as a "set", and
then use the original narrowing semantics between the classes.

This approach would solve the issue and would align with the original
semantics in most cases, but would also avoid the "absurd result".

Thoughts?
Thanks,
Nir

On Mon, Jan 11, 2021 at 7:56 AM Kevin Ma <[email-masked]> wrote:

> the advertisement of different footprint types narrows the dCDN's
> candidacy cumulatively." I believe that statement was referring to if
> multiple FCI messages were sent for the same capability but the messages
> had different footprints in them; I do not believe it was intended to apply
> to multiple footprints in the same message.  (I believe it stemmed from a
> protocol implementation question for how to override footprints and how to
> deal with footprints in sequential messages, which I had addressed in my
> original capabilities protocol draft:
> https://mailarchive.ietf.org/arch/msg/cdni/3GVjUbBNsf2gV8fQUhcVBRID_mU/
> ).  All of the less relevant material was moved to appendices (per:
> https://mailarchive.ietf.org/arch/msg/cdni/2gLvfnlbpJjIo57bER72kIiSZsk/
> ).  In hindsight we probably could've done more to clean up the appendices,
> but as is always the case, we did not have the benefit of hindsight at the

---

From: Guillaume Bichot <[email-masked]>
Date: Mon, 11 Jan 2021 22:35:48 +0000

Hi Ni,
What your proposed below goes into the same direction that I thought of except that it brings changes in the protocol adding modifying the MI.Footprint object structure with this new footprint class. I proposed to just change the semantic without touching the syntax. So  I thought my proposal simpler to deal with.

However I realized that it is impossible to indicate two different IP address ranges/blocks, each constrained by a different geographical area or vice-versa.
So what we need is may be something like this.

         "footprints": [

             {

                 "footprint-ip-type": "asn",

                 "footprint-ip-value": ["17192"]

                  "footprint-geo-type": "iso3166code",

                 "footprint-geo-value": ["ny"]

             },

             {

                 "footprint-ip-type": "asn",

                 "footprint-ip-value": ["18345"]

                  "footprint-geo-type": "iso3166code",

                 "footprint-geo-value": ["wa",]

             }

         ]
May be this will never appear though and in that case I would favor an approach that not touch the existing syntax.

Guillaume

broadpeak

From: Nir Sopher <[email-masked]>
Sent: Monday, January 11, 2021 5:46 PM
To: Kevin Ma <[email-masked]>
Cc: Guillaume Bichot <[email-masked]>; [email-masked]
Subject: Re: [CDNi] New Internet Draft: draft-sopher-cdni-footprint-types-extensions

Indeed, disregarding the statement in the appendix would negate the need for the ipv4v6cidr.
However, IIUC, this would weaken the protocol:
Take for example an integration where we would like the footprint to cover only clients within a Europe wide spread ASN, but only in Belgium, or only the NY clients of a US-wide ASN. The protocol when disregarding the "narrowing semantics" statement would not be able to specify it (while in the original semantics it is definable).

One can argue we need to be able to create some boolean expression. ORing and ANDing footprints.
I think a better approach (Guillaume, it might be the direction you were pointing at), is to define now a "footprint object class", grouping the "footprint object types"

  1.  Footprint Class: ip
Grouped footprint-types:

     *   ipv4cidr
     *   ipv6cidr
     *   asn

  1.  Footprint Class: geo
Grouped footprint-types:

     *   countrycode
     *   iso3166code
When a footprint objects list is composed from multiple footprint-object classes, we should first merge objects from the same class as a "set", and then use the original narrowing semantics between the classes.

This approach would solve the issue and would align with the original semantics in most cases, but would also avoid the "absurd result".

Thoughts?
Thanks,
Nir

On Mon, Jan 11, 2021 at 7:56 AM Kevin Ma <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

  It's been a while since we had the FCI debates, and FCI has a rather complex history, so I've had to refresh my memory.

  wrt the text in question: "Multiple footprint constraints are additive: the advertisement of different footprint types narrows the dCDN's candidacy cumulatively." I believe that statement was referring to if multiple FCI messages were sent for the same capability but the messages had different footprints in them; I do not believe it was intended to apply to multiple footprints in the same message.  (I believe it stemmed from a protocol implementation question for how to override footprints and how to deal with footprints in sequential messages, which I had addressed in my original capabilities protocol draft: https://tools.ietf.org/html/draft-ma-cdni-capabilities-04#section-2<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ma-cdni-capabilities-04%23section-2&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473835824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=80AKZbxTCmE%2BEPJ9BS0nzyT5N67Kc0e3YMTZ3mvYte0%3D&reserved=0> and https://tools.ietf.org/html/draft-ma-cdni-capabilities-04#section-3.2<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ma-cdni-capabilities-04%23section-3.2&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473845779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qu9p49G%2FgjUZL%2FbJyJHlZWmp07SWhTIDPYMPq3g2YjQ%3D&reserved=0> .)

  In addition, I don't know that we should give any normative weight to a non-normative statement in an appendix.  As the draft points out (https://tools.ietf.org/html/draft-sopher-cdni-footprint-types-extensions-01#section-2.1<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-sopher-cdni-footprint-types-extensions-01%23section-2.1&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473845779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5WdTm35zpiWUOH9WPViA78UdJ8GcIqpCVYzh6zs%2BSgs%3D&reserved=0> ), applying the statement to the list of footprints in a single message produces an absurd result (i.e., disjoint footprints produce an empty set of footprints), and that was certainly not the intention (which I think we can infer from the prevention of such a result in the protocol drafts).

> Frankly, this is very strange that the statement is almost hidden in a kind of annex  whereas it could have been located in section 5 in a proper dedicated section.

  Coming out of IETF 90 and 91, we had decided to focus the FCI semantics draft on just the information that needed to be advertised and separate out the protocol specifications (see: https://mailarchive.ietf.org/arch/msg/cdni/3GVjUbBNsf2gV8fQUhcVBRID_mU/<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcdni%2F3GVjUbBNsf2gV8fQUhcVBRID_mU%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473855737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cKgbpTM8n4dEa35J%2BIl9Xsl183pgqVU29Cs3exn4phE%3D&reserved=0> ).  All of the less relevant material was moved to appendices (per: https://mailarchive.ietf.org/arch/msg/cdni/2gLvfnlbpJjIo57bER72kIiSZsk/<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcdni%2F2gLvfnlbpJjIo57bER72kIiSZsk%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473855737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9OE9ba%2F9GO2gOHYfVH%2FWUHEOSgrVwgoqGKAHN1WU4pY%3D&reserved=0> ).  In hindsight we probably could've done more to clean up the appendices, but as is always the case, we did not have the benefit of hindsight at the time.  The decision was made to rely on ALTO as a transport protocol, which defines its own footprint type and enforcement rules (see: https://tools.ietf.org/html/draft-ietf-alto-cdni-request-routing-alto-14#section-4.1<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-alto-cdni-request-routing-alto-14%23section-4.1&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473865685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9SyMTKHI9d8DN2HBKil1WDtiLVI79fe9E4m6kL2SkYk%3D&reserved=0> ).

  We probably also could have done more to specify the interpretation of the footprint list, but I think that was just delegated to the protocol specs.  At the time, there was contentious debate between advertising of footprints vs advertising of capabilities (thus: https://tools.ietf.org/html/rfc8008#section-3<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8008%23section-3&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473865685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y86bPSFk1TbfWkKYZdkBkrd5yKd8RBD%2Bga8UnTzCHkU%3D&reserved=0> ), and our focus was clarifying the advertisement of capabilities with footprint restrictions and completing the semantics draft so we could move forward with the protocol draft(s).

  If folks feel strongly about the appendix being confusing, we could consider filing an errata?

Sanjay/Nir,

  If we disregard the statement in the appendix and assume that within a single message, multiple footprint types are allowed and are considered as a set, does that negate the need for the proposed ipv4v6cidr footprint type?

  wrt the iso3166code footprint type, I don't see any issue with it if folks feel it would be useful.

thanx!

--  Kevin J. Ma

On Sun, Jan 10, 2021 at 5:54 PM Guillaume Bichot <[email-masked]<mailto:[email-masked]>> wrote:
Hi Sanjay & Nir.

{

     "capabilities": [

       {

         },

         "footprints": [

             {

             },

             {

             }

         ]

       }

     ]

   }

Examples

"ipv4cidr", ["192.0.2.0/24<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.0.2.0%2F24&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473865685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qhDrJFd75ODqch9xfSl786j%2FU9jnxZaQXpijMMk7ulU%3D&reserved=0>", "192.0.2.1/24<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.0.2.1%2F24&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473875648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lBrFIWDHJA8xPSl2GCQOwTdpvdlP3MLPRwKTelQXZIA%3D&reserved=0>"]

"ipv4cidr", ["192.0.2.2/28<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.0.2.2%2F28&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473875648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=s3kHyObYg4511FaZnuafGvrSGxOo22oeQkzbIjOBCFU%3D&reserved=0>"]

"ipv4cidr", ["192.0.2.0/24<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.0.2.0%2F24&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473875648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=d01Jf1JDgKB8bmG9soVi6I6oBQpZK%2FOmc9tWGZjKNmo%3D&reserved=0>"]

Guillaume

Hi,

We have submitted draft-sopher-cdni-footprint-types-extensions<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dsopher-2Dcdni-2Dfootprint-2Dtypes-2Dextensions_%26d%3DDwMFaQ%26c%3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ%26r%3DXniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM%26m%3DTs5uj_nZmoHgi7pPldjWKsDPgmeeiO_RkotsI8zZD-E%26s%3DoWZZ4TjWJsq7Ao899RmyOUwUgAjNYeVlksfkKAy-UeA%26e%3D&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473885602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MlGQ01iXtJTpEtAq%2BYBBKioAXJ8LP93cPjv5RUN2IKE%3D&reserved=0> that extends RFCs 8006/8008 in order to address the following issue:

In the submitted draft:

_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcdni&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473885602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=83I1fHiglY1ep%2BLAllbVfNpUNqUduGNCkv19G2iuV7M%3D&reserved=0>
_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcdni&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cab6f7b501902465095e308d8b6505728%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637459803473895560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XDmIu2LYZkGwG81pOrJPLct3tO%2BN7Xf3wxdWT%2FZ40Q4%3D&reserved=0>

---

From: Kevin Ma <[email-masked]>
Date: Mon, 11 Jan 2021 22:50:50 -0500

Hi Nir,

> IIUC, this would weaken the protocol:

  Again, just to be clear, the FCI semantics RFC was never intended to
define a "protocol".  The purpose was only to define a common message
format.  It is arguable whether the interpretation of the footprint list
entries should be protocol specific, but I think we can infer that we felt
such interpretations were protocol specific and thus beyond the scope of
the FCI semantics RFC.  We probably could've made that more clear, but
again, hindsight.

> define now a "footprint object class", grouping the "footprint object
types"

  wrt the grouping proposal, it is not clear to me that there is a natural
grouping for footprint types or how future footprint types would be matched
to a group, .e.g., should asn always be combined with ipv4/ipv6, and why
not combine IPs with countries?  There will likely always be counter
examples where a fixed grouping doesn't fit a certain scenario or there is
a difference of opinion on what the natural groupings should be.  These are
the types of things we were trying to avoid in defining a generic message
envelope and wanted to delegate to protocol implementation specs (e.g., the
altopid footprint type solves the ipv4/ipv6 problem for the ALTO FCI
implementation,
https://tools.ietf.org/html/draft-ietf-alto-cdni-request-routing-alto-14#section-4.1
).

  Would the intent here be to enforce a grouping proposal on all FCI
implementations?  Or is there a specific FCI protocol you have in mind?  Is
SVA intending to use ALTO for FCI?

thanx!

--  Kevin J. Ma

On Mon, Jan 11, 2021 at 11:45 AM Nir Sopher <[email-masked]> wrote:

>>   wrt the text in question: "Multiple footprint constraints are
>> additive: the advertisement of different footprint types narrows the
>> dCDN's candidacy cumulatively." I believe that statement was referring
>> to if multiple FCI messages were sent for the same capability but the
>> messages had different footprints in them; I do not believe it was intended
>> to apply to multiple footprints in the same message.  (I believe it stemmed
>> from a protocol implementation question for how to override footprints and
>> how to deal with footprints in sequential messages, which I had addressed
>> in my original capabilities protocol draft:
>>>    1. We add a new usecase of dCDN advertising a footprint that
>>>    consists of both IPv4 and IPv6 client addresses, by defining a new
>>>    "IPv4v6CIDR" Footprint Type.

---

From: Nir Sopher <[email-masked]>
Date: Tue, 12 Jan 2021 14:25:27 +0200

Hi Kevin and Guillaume,

I did not intend to change the footprint objects. I assume we can just
specify in the new RFC the class of each type and the semantic would apply
on the current syntax.
If we make changes in the syntax, we can do it simply by defining the
footprints in 2 layers. For example:
"footprints": [
    [
        {
            "footprint-type": "iso3166code",
            "footprint-value": ["ca", "us-ny"]
        }
    ],
    [
        {
            "footprint-type": "ipv4",
            "footprint-value": ["1.2.3.0/24"]
        },
        {
            "footprint-the type": "ipv6",
            "footprint-value": ["2001:db8::/32"]
        }
    ]
]

The semantic would be considering the inner lists objects as sets, and then
narrowing the outer list results.
This would not force us to define the class of each type.

The change I describe above can be valid to all FCI implementations.
Note that the footprint types are also used by the CDNI Metadata
LocationACL objects <https://tools.ietf.org/html/rfc8006#section-4.2.2.2>,
where IIUC the list of objects is considered as a set.

WRT the ALTO PID, I'll need to look deeper into it

Nir

On Tue, Jan 12, 2021 at 5:51 AM Kevin Ma <[email-masked]> wrote:

>> Take for example an integration where we would like the footprint to
>> cover only clients within a Europe wide spread ASN, but only in Belgium, or
>> only the NY clients of a US-wide ASN. The protocol when disregarding the
>>>   In addition, I don't know that we should give any normative weight to
>>> a non-normative statement in an appendix.  As the draft points out (
>>> > Frankly, this is very strange that the statement is almost hidden in
>>> a kind of annex  whereas it could have been located in section 5 in a
>>> proper dedicated section.
>>>
>>>   Coming out of IETF 90 and 91, we had decided to focus the FCI
>>> semantics draft on just the information that needed to be advertised and
>>> separate out the protocol specifications (see:

---

From: Kevin Ma <[email-masked]>
Date: Tue, 12 Jan 2021 23:19:16 -0500

Hi Nir,

  Correct.  In RFC8006 section 4.2.2.1, the footprint list is treated as a
cumulative list.  I would expect the same to be true of the footprint list
in the FCI base advertisement object (in section 5.1 of RFC8008).  So, the
example in section 2.1 of your draft:

    [{"footprint-type": "ipv4cidr","footprint-value": ["192.0.2.0/24"]},

  {"footprint-type": "ipv6cidr","footprint-value": ["2001:db8::/32"]}]

  would cover the union of the ipv4 and the ipv6 prefixes, not the
intersection.

  If you wanted to create more complex multi-footprint-intersection rules,
that could be done by implementing a custom footprint type with the
intersection rules clearly defined.

thanx.

--  Kevin J. Ma

On Tue, Jan 12, 2021 at 7:25 AM Nir Sopher <[email-masked]> wrote:

> The semantic would be considering the inner lists objects as sets, and
> then narrowing the outer list results.
>>   wrt the grouping proposal, it is not clear to me that there is a
>> natural grouping for footprint types or how future footprint types would be
>> matched to a group, .e.g., should asn always be combined with ipv4/ipv6,
>> and why not combine IPs with countries?  There will likely always be
>> counter examples where a fixed grouping doesn't fit a certain scenario or
>> there is a difference of opinion on what the natural groupings should be.
>> These are the types of things we were trying to avoid in defining a generic
>> message envelope and wanted to delegate to protocol implementation specs
>> (e.g., the altopid footprint type solves the ipv4/ipv6 problem for the ALTO
>> FCI implementation,
>>>>   We probably also could have done more to specify the interpretation
>>>> of the footprint list, but I think that was just delegated to the protocol
>>>>   If we disregard the statement in the appendix and assume that within
>>>> a single message, multiple footprint types are allowed and are considered
>>>> as a set, does that negate the need for the proposed ipv4v6cidr footprint
>>>> type?
>>>>
>>>>>    - Sections 4.3.5 and 4.3.6 of [RFC8006] specify the "IPv4CIDR"
>>>>>    and  "IPv6CIDR" footprint types, respectively, for listing IP addresses
>>>>>    blocks.  Using Footprint Objects of these types, one can define an FCI
>>>>>    Capability Advertisement Object footprint constraints that match IPv4 or
>>>>>    IPv6 clients. Also as described in section 5 of RFC 8008, the FCI
>>>>>    2. We also add support for ISO3166Code Footprint Type, based on
>>>>>    ISO 3166 country codes and regions definition. This Footprint Type allows
>>>>>    the dCDN to advertise a footprint based on a specific region, for example a
>>>>>    state in the USA.
>>>>>

---

From: Nir Sopher <[email-masked]>
Date: Wed, 13 Jan 2021 08:33:42 +0200

Thanks Kevin,

I'll summarize your suggestion as I understand it.
You suggest to
1. Remove the narrowing semantics comment from the appendix (just write in
the new rfc that it should be disregarded?)
2. Define a new footprint type: intersection  (name: tbd)

So if we want to point at ips 1.2.3.0/24 and 2001:db8::/32 only in the US
we would like to intersect
"footprints": [
    {
        "footprint-type": "iso3166code",
        "footprint-value": ["us"]
    }
]

with
"footprints": [
    {

To create:
"footprints": [
    {
        "footprint-type": "intersection",
        "footprint-value": [
            [
                {
                    "footprint-type": "iso3166code",
                    "footprint-value": ["us"]
                }
            ],
            [
                {
                    "footprint-type": "ipv4",
                    "footprint-value": ["1.2.3.0/24"]
                },
                {
                    "footprint-the type": "ipv6",
                    "footprint-value": ["2001:db8::/32"]
                }
            ]
        ]
    }

What would you say about keeping the narrowing semantics and define a
"union" (name: tbd) instead?
It feels more natural to me, and it does not break the definitions done in
RFC-8008 which might have came from a deeper discussion you had back then.

"footprints": [
    {
        "footprints": [
            {
                "footprint-type": "iso3166code",
                "footprint-value": ["us"]
            },
            {
                "footprint-type": "union",
                "footprint-value": [
                    {
                        "footprint-type": "ipv4",
                        "footprint-value": ["1.2.3.0/24"]
                    },
                    {
                        "footprint-the type": "ipv6",
                        "footprint-value": ["2001:db8::/32"]
                    }
                ]
            }
        ]
    }

Thanks
Nir

On Wed, Jan 13, 2021, 06:19 Kevin Ma <[email-masked]> wrote:

>>>> I think a better approach (Guillaume, it might be the direction you
>>>> were pointing at), is to define now a "footprint object class",
>>>> grouping the "footprint object types"
>>>>
>>>>    1. Footprint Class: ip
>>>>    Grouped footprint-types:
>>>>       1. ipv4cidr
>>>>       2. ipv6cidr
>>>>       3. asn
>>>>    2. Footprint Class: geo
>>>>    Grouped footprint-types:
>>>>       1. countrycode
>>>>       2. iso3166code
>>>>
>>>> When a footprint objects list is composed from
>>>> multiple footprint-object classes, we should first merge objects from the
>>>> same class as a "set", and then use the original narrowing semantics
>>>> between the classes.
>>>>
>>>>> dCDN's candidacy cumulatively." I believe that statement was
>>>>> referring to if multiple FCI messages were sent for the same capability but
>>>>> the messages had different footprints in them; I do not believe it was
>>>>> intended to apply to multiple footprints in the same message.  (I believe
>>>>> it stemmed from a protocol implementation question for how to override
>>>>> footprints and how to deal with footprints in sequential messages, which I
>>>>> had addressed in my original capabilities protocol draft:
>>>>>   In addition, I don't know that we should give any normative weight
>>>>> to a non-normative statement in an appendix.  As the draft points out (
>>>>> > Frankly, this is very strange that the statement is almost hidden
>>>>> in a kind of annex  whereas it could have been located in section 5 in a

---

From: Nir Sopher <[email-masked]>
Date: Wed, 13 Jan 2021 12:20:39 +0200

[Resending, with a clearer output examples]

Thanks Kevin,

with
"footprints": [
    {

To create:
    "footprints": [
        {
            "footprint-type": "footprint-intersection",
            "footprint-value": [
                {
                    "footprints": [
                        {

What would you say about keeping the narrowing semantics and define a
"union" (name: tbd) instead?
It feels more natural to me (I prefer ORs of ANDs vs. ANDs of ORs), and it
does not break the definitions done in RFC-8008 which might have came from
a deeper discussion you had back then.

"footprints": [
    {
        "footprints": [
            {

Thanks
Nir

On Wed, Jan 13, 2021 at 8:33 AM Nir Sopher <[email-masked]> wrote:

>>   Correct.  In RFC8006 section 4.2.2.1, the footprint list is treated as
>> a cumulative list.  I would expect the same to be true of the footprint
>> list in the FCI base advertisement object (in section 5.1 of RFC8008).  So,
>> the example in section 2.1 of your draft:
>>
>>   If you wanted to create more complex multi-footprint-intersection
>> rules, that could be done by implementing a custom footprint type with the
>>> LocationACL objects
>>> <https://tools.ietf.org/html/rfc8006#section-4.2.2.2>, where IIUC the
>>> list of objects is considered as a set.
>>>
>>>>>>   It's been a while since we had the FCI debates, and FCI has a
>>>>>> rather complex history, so I've had to refresh my memory.
>>>>>>
>>>>>>   If we disregard the statement in the appendix and assume that
>>>>>> within a single message, multiple footprint types are allowed and are
>>>>>> considered as a set, does that negate the need for the proposed ipv4v6cidr
>>>>>> footprint type?
>>>>>>

---

From: Kevin Ma <[email-masked]>
Date: Sun, 24 Jan 2021 23:52:44 -0500

Hi Nir,

> 1. Remove the narrowing semantics comment from the appendix (just write
in the new rfc that it should be disregarded?)

  I'm not sure we need a rewrite of the RFC.  I think if we wanted, we
could file an errata to clarify the appendix text.

> 2. Define a new footprint type: intersection  (name: tbd)

  Is there a use case that requires intersection of footprint types for
capability advertisement? It's not clear to me when intersecting a country
code with an IP address range would be needed?  The implication is that
some of the IP address range is outside the country while some is within,
or that they can move between countries, and that we don't know which IP
addresses are outside the country, but we would somehow be able to
determine that later when the request is processed?  Is this to deal with
VPN/tunneling detection?  That seems more like an ACL issue, than a
capabilitiy advertisement issue?

thanx.

--  Kevin J. Ma

---

From: Nir Sopher <[email-masked]>
Date: Wed, 27 Jan 2021 07:59:45 +0200

Hi Kevin,

We encountered use cases that require intersection of footprint types
mainly between ASNs and ISO-3166 codes.
E.g. when a federation of dCDNs, would like to provide a footprint object
that covers a certain ISP in the state of NY.
This may be due to partial coverage of the ASN with cache nodes.

If for example an ISP (dCDN) deployed nodes only in NY, we would like the
uCDN delegate only NY clients to the ISP dCDN.

Another example for tthe need to use an intersection of ASNs and Geo info
is when discussing capacity indication (discussed on another thread). The
capacity is associated with a specific location within the ASN.

One may argue that this can just be done using a list of the relevant IPs,
but it is not always the case, mainly as many uCDNs do not support
delegation based on IP list while they do support delegation based on
ASN/Geo.
Furthermore, in a DNS based delegation, where the name-server CNAMEs the
queried hostname to a dCDN target hostname, the client IP is not even
available to the uCDN at the delegation decision point.

Thanks,
Nir

On Mon, Jan 25, 2021, 06:52 Kevin Ma <[email-masked]> wrote:

>> So if we want to point at ips 1.2.3.0/24 and 2001:db8::/32 only in the
>> US we would like to intersect
>> "footprints": [
>>     {
>> It feels more natural to me, and it does not break the definitions done
>> in RFC-8008 which might have came from a deeper discussion you had back
>> then.
>>
>> "footprints": [
>>     {
>>         "footprints": [
>>             {
>>>>> > define now a "footprint object class", grouping the "footprint
>>>>> object types"
>>>>>
>>>>>>>   We probably also could have done more to specify the
>>>>>>> interpretation of the footprint list, but I think that was just delegated
>>>>>>> to the protocol specs.  At the time, there was contentious debate between
>>>>>>> advertising of footprints vs advertising of capabilities (thus:
>>>>>>>> *From:* CDNi [mailto:[email-masked] <[email-masked]>]
>>>>>>>> *On Behalf Of *Nir Sopher

---

From: Ori Finkelman <[email-masked]>
Date: Wed, 27 Jan 2021 09:44:57 +0200

Hi Nir,
This is an interesting use case, but I wonder if it is not solved by IP
ranges.
If the delegating CDN has to take a decision based on ASN and location, how
would they do that? how would they know the location of the client?  If
they know it by IP address wouldn't that mean that the same can be
achieved by IP range lists?

Thanks,
Ori

On Wed, Jan 27, 2021 at 8:00 AM Nir Sopher <[email-masked]> wrote:

>>>>   Correct.  In RFC8006 section 4.2.2.1, the footprint list is treated
>>>> as a cumulative list.  I would expect the same to be true of the footprint
>>>>>>   Again, just to be clear, the FCI semantics RFC was never intended
>>>>>> to define a "protocol".  The purpose was only to define a common message
>>>>>>> This approach would solve the issue and would align with the
>>>>>>> original semantics in most cases, but would also avoid the "absurd result".
>>>>>>>
>>>>>>> Thoughts?
>>>>>>> Thanks,
>>>>>>> Nir
>>>>>>>
>>>>>>>>   In addition, I don't know that we should give any normative
>>>>>>>> weight to a non-normative statement in an appendix.  As the draft points
>>>>>>>> out (
>>>>>>>> > Frankly, this is very strange that the statement is almost
>>>>>>>> hidden in a kind of annex  whereas it could have been located in section 5
>>>>>>>> in a proper dedicated section.
>>>>>>>>
>>>>>>>>>    2. We also add support for ISO3166Code Footprint Type, based
>>>>>>>>>    on ISO 3166 country codes and regions definition. This Footprint Type
>>>>>>>>>    allows the dCDN to advertise a footprint based on a specific region, for
>>>>>>>>>    example a state in the USA.
>>>>>>>>>

---

From: Nir Sopher <[email-masked]>
Date: Wed, 27 Jan 2021 11:26:35 +0200

Hi Ori,

Not necessarily.
Location can be derived from resolver (DNS cache) IP as well as resolving
Name Server location.
Another case is where the location can be derived from the queried hostname
- for example when we deal with State level "TV stations" each having a
different hostname.

Nir

On Wed, Jan 27, 2021, 09:45 Ori Finkelman <[email-masked]>
wrote:

> If the delegating CDN has to take a decision based on ASN and location,
> how would they do that? how would they know the location of the client?  If
>> One may argue that this can just be done using a list of the relevant
>> IPs, but it is not always the case, mainly as many uCDNs do not support
>>> > 1. Remove the narrowing semantics comment from the appendix (just
>>> write in the new rfc that it should be disregarded?)
>>>
>>>>>> I did not intend to change the footprint objects. I assume we can
>>>>>> just specify in the new RFC the class of each type and the semantic would
>>>>>> apply on the current syntax.
>>>>>> The semantic would be considering the inner lists objects as sets,
>>>>>> and then narrowing the outer list results.
>>>>>> <https://tools.ietf.org/html/rfc8006#section-4.2.2.2>, where IIUC
>>>>>> the list of objects is considered as a set.
>>>>>>
>>>>>>>> Take for example an integration where we would like the footprint
>>>>>>>> to cover only clients within a Europe wide spread ASN, but only in Belgium,
>>>>>>>> or only the NY clients of a US-wide ASN. The protocol when disregarding the
>>>>>>>>> https://tools.ietf.org/html/rfc8008#section-3 ), and our focus
>>>>>>>>> was clarifying the advertisement of capabilities with footprint
>>>>>>>>> restrictions and completing the semantics draft so we could move forward
>>>>>>>>> with the protocol draft(s).
>>>>>>>>>
>>>>>>>>>> *From:* CDNi [mailto:[email-masked]
>>>>>>>>>> <[email-masked]>] *On Behalf Of *Nir Sopher
>>>>>>>>>>    - Sections 4.3.5 and 4.3.6 of [RFC8006] specify the
>>>>>>>>>>    "IPv4CIDR" and  "IPv6CIDR" footprint types, respectively, for listing IP
>>>>>>>>>>    addresses blocks.  Using Footprint Objects of these types, one can define
>>>>>>>>>>    an FCI Capability Advertisement Object footprint constraints that
>>>>>>>>>>    match IPv4 or IPv6 clients. Also as described in section 5 of RFC 8008, the
>>>>>>>>>>    FCI Capability Advertisement Object includes an array of such CDNI
>>>>>>>>>>    Footprint Objects. The array of Footprint Objects has a "narrowing"
>>>>>>>>>>    semantic that prevents the usage of IPv4/IPv6 objects together in order to
>>>>>>>>>>    create a footprint constraint that matches IPv4 clients together with IPv6
>>>>>>>>>>    clients.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In the submitted draft:
>>>>>>>>>>

---

From: [email-masked]
Date: Fri, 29 Jan 2021 21:47:05 +0000

> 2. Define a new footprint type: intersection  (name: tbd)

  Is there a use case that requires intersection of footprint types for capability advertisement? It's not clear to me when intersecting a country code with an IP address range would be needed?  The implication is that some of the IP address range is outside the country while some is within, or that they can move between countries, and that we don't know which IP addresses are outside the country, but we would somehow be able to determine that later when the request is processed?  Is this to deal with VPN/tunneling detection?  That seems more like an ACL issue, than a capabilitiy advertisement issue?

One use case is the ability of uCDN delegate content based on ASN + State. Additionally, this use case may also want to intersect with a set of IP ranges for the state to further restrict to a specific serving region advertised by the dCDN.

Thanks
Sanjay

From: CDNi [mailto:[email-masked]] On Behalf Of Kevin Ma
Sent: Sunday, January 24, 2021 11:53 PM
To: Nir Sopher <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: [E] Re: [CDNi] New Internet Draft: draft-sopher-cdni-footprint-types-extensions

Hi Nir,

> 1. Remove the narrowing semantics comment from the appendix (just write in the new rfc that it should be disregarded?)

  I'm not sure we need a rewrite of the RFC.  I think if we wanted, we could file an errata to clarify the appendix text.

> 2. Define a new footprint type: intersection  (name: tbd)

  Is there a use case that requires intersection of footprint types for capability advertisement? It's not clear to me when intersecting a country code with an IP address range would be needed?  The implication is that some of the IP address range is outside the country while some is within, or that they can move between countries, and that we don't know which IP addresses are outside the country, but we would somehow be able to determine that later when the request is processed?  Is this to deal with VPN/tunneling detection?  That seems more like an ACL issue, than a capabilitiy advertisement issue?

thanx.

--  Kevin J. Ma

On Wed, Jan 13, 2021 at 1:33 AM Nir Sopher <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Kevin,

I'll summarize your suggestion as I understand it.
You suggest to
1. Remove the narrowing semantics comment from the appendix (just write in the new rfc that it should be disregarded?)
2. Define a new footprint type: intersection  (name: tbd)

So if we want to point at ips 1.2.3.0/24<https://urldefense.proofpoint.com/v2/url?u=http-3A__1.2.3.0_24&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=OUoradIkth5XucdcQQt36s_fntFRciwU3lK01yQ1jKI&e=> and 2001:db8::/32 only in the US we would like to intersect
"footprints": [
    {
        "footprint-type": "iso3166code",
        "footprint-value": ["us"]
    }
]

with
"footprints": [
    {
        "footprint-type": "ipv4",
        "footprint-value": ["1.2.3.0/24<https://urldefense.proofpoint.com/v2/url?u=http-3A__1.2.3.0_24&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=OUoradIkth5XucdcQQt36s_fntFRciwU3lK01yQ1jKI&e=>"]
    },
    {
        "footprint-the type": "ipv6",
        "footprint-value": ["2001:db8::/32"]
    }
]

To create:
"footprints": [
    {
                    "footprint-value": ["1.2.3.0/24<https://urldefense.proofpoint.com/v2/url?u=http-3A__1.2.3.0_24&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=OUoradIkth5XucdcQQt36s_fntFRciwU3lK01yQ1jKI&e=>"]

What would you say about keeping the narrowing semantics and define a "union" (name: tbd) instead?
It feels more natural to me, and it does not break the definitions done in RFC-8008 which might have came from a deeper discussion you had back then.

"footprints": [
    {
        "footprints": [
            {
                        "footprint-value": ["1.2.3.0/24<https://urldefense.proofpoint.com/v2/url?u=http-3A__1.2.3.0_24&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=OUoradIkth5XucdcQQt36s_fntFRciwU3lK01yQ1jKI&e=>"]

Thanks
Nir

On Wed, Jan 13, 2021, 06:19 Kevin Ma <[email-masked]<mailto:[email-masked]>> wrote:
Hi Nir,

> Note that the footprint types are also used by the CDNI Metadata LocationACL objects<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8006-23section-2D4.2.2.2&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=RJIGP2xW9o0hqiOyjQzI4gnNcRXgClEYgvvr1t_mmCU&e=>, where IIUC the list of objects is considered as a set.

  Correct.  In RFC8006 section 4.2.2.1, the footprint list is treated as a cumulative list.  I would expect the same to be true of the footprint list in the FCI base advertisement object (in section 5.1 of RFC8008).  So, the example in section 2.1 of your draft:

    [{"footprint-type": "ipv4cidr","footprint-value": ["192.0.2.0/24<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.0.2.0_24&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=2FxIiBugJina49_toPDWfx6c6CxzRqRPrvqfTPo9v1c&e=>"]},

  would cover the union of the ipv4 and the ipv6 prefixes, not the intersection.

  If you wanted to create more complex multi-footprint-intersection rules, that could be done by implementing a custom footprint type with the intersection rules clearly defined.

thanx.

--  Kevin J. Ma

On Tue, Jan 12, 2021 at 7:25 AM Nir Sopher <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kevin and Guillaume,

I did not intend to change the footprint objects. I assume we can just specify in the new RFC the class of each type and the semantic would apply on the current syntax.
If we make changes in the syntax, we can do it simply by defining the footprints in 2 layers. For example:
"footprints": [
    [
        {
            "footprint-type": "iso3166code",
            "footprint-value": ["ca", "us-ny"]
        }
    ],
    [
        {
            "footprint-type": "ipv4",
            "footprint-value": ["1.2.3.0/24<https://urldefense.proofpoint.com/v2/url?u=http-3A__1.2.3.0_24&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=OUoradIkth5XucdcQQt36s_fntFRciwU3lK01yQ1jKI&e=>"]
        },
        {
            "footprint-the type": "ipv6",
            "footprint-value": ["2001:db8::/32"]
        }
    ]
]

The semantic would be considering the inner lists objects as sets, and then narrowing the outer list results.
This would not force us to define the class of each type.

The change I describe above can be valid to all FCI implementations.
Note that the footprint types are also used by the CDNI Metadata LocationACL objects<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8006-23section-2D4.2.2.2&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=RJIGP2xW9o0hqiOyjQzI4gnNcRXgClEYgvvr1t_mmCU&e=>, where IIUC the list of objects is considered as a set.

Nir

On Tue, Jan 12, 2021 at 5:51 AM Kevin Ma <[email-masked]<mailto:[email-masked]>> wrote:
Hi Nir,

> IIUC, this would weaken the protocol:

  Again, just to be clear, the FCI semantics RFC was never intended to define a "protocol".  The purpose was only to define a common message format.  It is arguable whether the interpretation of the footprint list entries should be protocol specific, but I think we can infer that we felt such interpretations were protocol specific and thus beyond the scope of the FCI semantics RFC.  We probably could've made that more clear, but again, hindsight.

> define now a "footprint object class", grouping the "footprint object types"

  wrt the grouping proposal, it is not clear to me that there is a natural grouping for footprint types or how future footprint types would be matched to a group, .e.g., should asn always be combined with ipv4/ipv6, and why not combine IPs with countries?  There will likely always be counter examples where a fixed grouping doesn't fit a certain scenario or there is a difference of opinion on what the natural groupings should be.  These are the types of things we were trying to avoid in defining a generic message envelope and wanted to delegate to protocol implementation specs (e.g., the altopid footprint type solves the ipv4/ipv6 problem for the ALTO FCI implementation, https://tools.ietf.org/html/draft-ietf-alto-cdni-request-routing-alto-14#section-4.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dalto-2Dcdni-2Drequest-2Drouting-2Dalto-2D14-23section-2D4.1&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=Jye1oA4OunxCMeY4yEg5uCF4aYTkfvSdSlNhjtVSCwQ&e=> ).

  Would the intent here be to enforce a grouping proposal on all FCI implementations?  Or is there a specific FCI protocol you have in mind?  Is SVA intending to use ALTO for FCI?

thanx!

--  Kevin J. Ma

On Mon, Jan 11, 2021 at 11:45 AM Nir Sopher <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Guillaume and Kevin,

  1.  Footprint Class: ip
Grouped footprint-types:

     *   ipv4cidr
     *   ipv6cidr
     *   asn

  1.  Footprint Class: geo
Grouped footprint-types:

     *   countrycode
     *   iso3166code

Thoughts?
Thanks,
Nir

  wrt the text in question: "Multiple footprint constraints are additive: the advertisement of different footprint types narrows the dCDN's candidacy cumulatively." I believe that statement was referring to if multiple FCI messages were sent for the same capability but the messages had different footprints in them; I do not believe it was intended to apply to multiple footprints in the same message.  (I believe it stemmed from a protocol implementation question for how to override footprints and how to deal with footprints in sequential messages, which I had addressed in my original capabilities protocol draft: https://tools.ietf.org/html/draft-ma-cdni-capabilities-04#section-2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dma-2Dcdni-2Dcapabilities-2D04-23section-2D2&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=iC10LHoXo3Stwewzvrq1CExXAZMq2NMpu9igFB2vwHM&e=> and https://tools.ietf.org/html/draft-ma-cdni-capabilities-04#section-3.2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dma-2Dcdni-2Dcapabilities-2D04-23section-2D3.2&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=2q5AQBuD-vJSqKgILDBXSFVDK7eKltkZ5hbPa_nf6hE&e=> .)

  In addition, I don't know that we should give any normative weight to a non-normative statement in an appendix.  As the draft points out (https://tools.ietf.org/html/draft-sopher-cdni-footprint-types-extensions-01#section-2.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsopher-2Dcdni-2Dfootprint-2Dtypes-2Dextensions-2D01-23section-2D2.1&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=RqMWCLD5NKg8_9APT0mS5QhLlhdtKqm52KRuH2p06kU&e=> ), applying the statement to the list of footprints in a single message produces an absurd result (i.e., disjoint footprints produce an empty set of footprints), and that was certainly not the intention (which I think we can infer from the prevention of such a result in the protocol drafts).

> Frankly, this is very strange that the statement is almost hidden in a kind of annex  whereas it could have been located in section 5 in a proper dedicated section.

  Coming out of IETF 90 and 91, we had decided to focus the FCI semantics draft on just the information that needed to be advertised and separate out the protocol specifications (see: https://mailarchive.ietf.org/arch/msg/cdni/3GVjUbBNsf2gV8fQUhcVBRID_mU/<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_cdni_3GVjUbBNsf2gV8fQUhcVBRID-5FmU_&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=-vj7k3j648xF0-uvpkReL3jFrh2InqRWTXcyo5JUMKQ&e=> ).  All of the less relevant material was moved to appendices (per: https://mailarchive.ietf.org/arch/msg/cdni/2gLvfnlbpJjIo57bER72kIiSZsk/<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_cdni_2gLvfnlbpJjIo57bER72kIiSZsk_&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=UQJWA0Xz1faF_4FNG9eCtHib0yF3xim5qgnd710-Yl0&e=> ).  In hindsight we probably could've done more to clean up the appendices, but as is always the case, we did not have the benefit of hindsight at the time.  The decision was made to rely on ALTO as a transport protocol, which defines its own footprint type and enforcement rules (see: https://tools.ietf.org/html/draft-ietf-alto-cdni-request-routing-alto-14#section-4.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dalto-2Dcdni-2Drequest-2Drouting-2Dalto-2D14-23section-2D4.1&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=Jye1oA4OunxCMeY4yEg5uCF4aYTkfvSdSlNhjtVSCwQ&e=> ).

  We probably also could have done more to specify the interpretation of the footprint list, but I think that was just delegated to the protocol specs.  At the time, there was contentious debate between advertising of footprints vs advertising of capabilities (thus: https://tools.ietf.org/html/rfc8008#section-3<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8008-23section-2D3&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=Bxsj8S4y_lobc6Le6A-aoUTFuz_bhnO7aPgz6JXKQAA&e=> ), and our focus was clarifying the advertisement of capabilities with footprint restrictions and completing the semantics draft so we could move forward with the protocol draft(s).

Sanjay/Nir,

thanx!

--  Kevin J. Ma

{

     "capabilities": [

       {

         },

         "footprints": [

             {

             },

             {

             }

         ]

       }

     ]

   }

Examples

"ipv4cidr", ["192.0.2.0/24<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.0.2.0_24&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=2FxIiBugJina49_toPDWfx6c6CxzRqRPrvqfTPo9v1c&e=>", “192.0.2.1/24<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.0.2.1_24&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=Wyx6CG5ijbPdqRAjIlA6w_kn-lvndpuaiqn4O6-NZJ8&e=>”]

“ipv4cidr”, [“192.0.2.2/28<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.0.2.2_28&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=q5wsQHRUiXKi3KtKJf8KskLAtp_wrfju5K5qS7TvPQg&e=>”]

"ipv4cidr", ["192.0.2.0/24<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.0.2.0_24&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=2FxIiBugJina49_toPDWfx6c6CxzRqRPrvqfTPo9v1c&e=>"]

Guillaume

Hi,

We have submitted draft-sopher-cdni-footprint-types-extensions<https://urldefense.proofpoint.com/v2/url?u=https-3A__eur02.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Fdatatracker.ietf.org-5Fdoc-5Fdraft-2D2Dsopher-2D2Dcdni-2D2Dfootprint-2D2Dtypes-2D2Dextensions-5F-2526d-253DDwMFaQ-2526c-253DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6-5F-5F0PomBTQ-2526r-253DXniVbishGiO2Ao9hKqSc-2DhTVIWCi3T-2Dx6GdHR4ZTgoM-2526m-253DTs5uj-5FnZmoHgi7pPldjWKsDPgmeeiO-5FRkotsI8zZD-2DE-2526s-253DoWZZ4TjWJsq7Ao899RmyOUwUgAjNYeVlksfkKAy-2DUeA-2526e-253D-26data-3D04-257C01-257Cguillaume.bichot-2540broadpeak.tv-257Cf6b67a86cc4b44ff6b7a08d8a83b82a1-257C0ebe44eac9c9438da0407e699f358ed4-257C0-257C0-257C637444320869999346-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C1000-26sdata-3DYxIzX3bst5GAicrOxFI-252BqfRZYO65-252Fwh07pDTwoYrrJg-253D-26reserved-3D0&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=199qR-xhUGFpMQz64HEyx_O2YsGrbZlcYnEtNl4_EBw&e=> that extends RFCs 8006/8008 in order to address the following issue:

In the submitted draft:

_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_cdni&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=ADdyDaI_qgEbwCeWmWy1RQ3zOVUBNUmJKDkCoPDz3Yk&e=>
_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_cdni&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=45D4ykvMhImJU63a0VFMn9_wQ1ws5DK3Gg76md8BFS8&s=ADdyDaI_qgEbwCeWmWy1RQ3zOVUBNUmJKDkCoPDz3Yk&e=>