Subject: [CDNi] Root object not defined in RFC8008: A bug ?

From: Guillaume Bichot <[email-masked]>
Date: Tue, 6 Jul 2021 13:04:24 +0000

Hi all,

Do not know whether it is a bug but in RFC8008 (FCI), there is no definition of  the  [root] object transporting the list of  base advertisement objects (FCIBase).  There is a "capabilities" property that is used  in all examples (e.g. 5.3.1) but this property is defined nowhere in the RFC. Consequently, In our SVA implementation, I did not consider that property as a standard property for now. For being considered, I would have read something like the following.

5.1.  Capabilities object

The Capabilities object is the entry point into the CDNI capabilities hierarchy. It contains an array of base advertisement objects.

      Property: capabilities

         Description: Array of FCIbase objects. MUST be evaluated in the order they appear.

         Type: Array of FCIbase objects.

         Mandatory-to-Specify: Yes.

5.2.  Base Advertisement Object

...

What do you think?

Guillaume

Guillaume Bichot
Principal Engineer, Head of Exploration

m: +33 685 597 666    p: +33 222 740 350
[email-masked]<mailto:[email-masked]>
[Logo]<https://www.broadpeak.tv/>

[twitter]<https://twitter.com/broadpeak>
[linkedin]<https://www.linkedin.com/company/broadpeak_2/>
[website]<https://broadpeak.tv/>

---

From: Kevin Ma <[email-masked]>
Date: Thu, 15 Jul 2021 00:44:11 -0400

Hi Guillaume,

  You make a fair point about the use of the capabilities root object in
the examples.  There's an obvious need for a root object to make the json
valid, but within the context of FCI semantics, arguably it is not strictly
necessary to define in RFC8008.  RFC8008 does not define a transport
protocol, and I believe the thought behind not defining the root object is
that the transport protocol spec could define whatever root object it
wanted without affecting the advertisement semantics.

  The "official" transport for FCI is ALTO,
and draft-ietf-alto-cdni-request-routing-alto defines the CDNIAdvertisementData
object that encapsulates the BaseAdvertisementObjects (
https://datatracker.ietf.org/doc/html/draft-ietf-alto-cdni-request-routing-alto-16#section-3.6
).

>  I did not consider that property as a standard property for now.

  I believe you have the correct interpretation, i.e., there is no
standardization of the root object in RFC8008.

thanx.

--  Kevin J. Ma

On Tue, Jul 6, 2021 at 9:04 AM Guillaume Bichot <
[email-masked]> wrote:

> Hi all,
>
>
>
> Do not know whether it is a bug but in RFC8008 (FCI), there is no
> definition of  the  [root] object transporting the list of  base
> advertisement objects (FCIBase).  There is a “capabilities” property that
> is used  in all examples (e.g. 5.3.1) but this property is defined nowhere
> in the RFC. Consequently, In our SVA implementation, I did not consider
> that property as a standard property for now. For being considered, I would
> have read something like the following.
>
>
>
>
>
> *5.1.  Capabilities object*
>
>
>
> *5.2.  Base Advertisement Object*
>
>
>
> *...*
>
>
>
> What do you think?
>
>
>
> Guillaume
>
>
>
>
>
>
>
> *Guillaume Bichot*
> *m:* +33 685 597 666    *p:* +33 222 740 350
>
> [email-masked] <[email-masked]>
>
>  <https://www.broadpeak.tv/>
>
>
>
>  <https://twitter.com/broadpeak>
>
>  <https://www.linkedin.com/company/broadpeak_2/>
>
>  <https://broadpeak.tv/>
>
>
>
>
>

---

From: Guillaume Bichot <[email-masked]>
Date: Thu, 15 Jul 2021 07:10:34 +0000

Kevin, it is not about the transport protocol but the data model. Beyond the root object , there is the property "capabilities" that is defined nowhere but is part  of the data model (and used in all examples in RFC8008). It should be part of the RFC 8080 spec I think.

At least the examples are confusing and the way Alto has implemented this confirms the problem. In Alto, they ignore that "capabilities"  property and somehow renamed it "capabilities-with-footprints". Changing RFC8008 will make Alto not compatible and vice-versa.. This said, we do not use ALTO in SVA.

In conclusion, we have the choice to either adopt the "capabilities"  property or the "capabilities-with-footprints" of the super object whatever it is.
Guillaume

Guillaume Bichot
Principal Engineer, Head of Exploration
broadpeak
m: +33 685 597 666    p: +33 222 740 350
[email-masked]

From: Kevin Ma <[email-masked]>
Sent: Thursday, July 15, 2021 6:44 AM
To: Guillaume Bichot <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [CDNi] Root object not defined in RFC8008: A bug ?

Hi Guillaume,

  You make a fair point about the use of the capabilities root object in the examples.  There's an obvious need for a root object to make the json valid, but within the context of FCI semantics, arguably it is not strictly necessary to define in RFC8008.  RFC8008 does not define a transport protocol, and I believe the thought behind not defining the root object is that the transport protocol spec could define whatever root object it wanted without affecting the advertisement semantics.

  The "official" transport for FCI is ALTO, and draft-ietf-alto-cdni-request-routing-alto defines the CDNIAdvertisementData object that encapsulates the BaseAdvertisementObjects (https://datatracker.ietf.org/doc/html/draft-ietf-alto-cdni-request-routing-alto-16#section-3.6<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-alto-cdni-request-routing-alto-16%23section-3.6&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C5f8c0508bad54e55df6d08d9474b39a7%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637619210687437646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Kwyafa01rXayWPXpsFzJaQgDHcf1dNLiUmc%2F2lel2a0%3D&reserved=0>).

>  I did not consider that property as a standard property for now.

  I believe you have the correct interpretation, i.e., there is no standardization of the root object in RFC8008.

thanx.

--  Kevin J. Ma

On Tue, Jul 6, 2021 at 9:04 AM Guillaume Bichot <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

5.1.  Capabilities object

      Property: capabilities

...

What do you think?

Guillaume

Guillaume Bichot

m: +33 685 597 666    p: +33 222 740 350
[email-masked]<mailto:[email-masked]>
[Logo]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.broadpeak.tv%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C5f8c0508bad54e55df6d08d9474b39a7%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637619210687447601%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WWC5V831uhpgnYM2wFiO7iFdJ6jKAvoXrTss8ACceZI%3D&reserved=0>

[twitter]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fbroadpeak&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C5f8c0508bad54e55df6d08d9474b39a7%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637619210687447601%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sB3ZCj2xufpWXtjjOVwmzQUgkr3EF2a7IeU2pj2cm6k%3D&reserved=0>
[linkedin]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fbroadpeak_2%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C5f8c0508bad54e55df6d08d9474b39a7%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637619210687457557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fQIPxEhD4Y%2B9oNLL6b06%2FfYeMfBPpa00hN9MdoBkanM%3D&reserved=0>
[website]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbroadpeak.tv%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C5f8c0508bad54e55df6d08d9474b39a7%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637619210687457557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iiRQUVNJJmQanas%2FN0Dw1ISvC7k7%2BUWQScOj%2FBKjp4I%3D&reserved=0>

---

From: Kevin Ma <[email-masked]>
Date: Sat, 24 Jul 2021 01:14:51 -0400

Hi Guillaume,

> there is the property “capabilities” that is defined nowhere but is part
of the data model (and used in all examples in RFC8008)

  Again, I understand/agree that "capabilities" is not defined in RFC8008
but shows up in the examples -- but I don't think that implies (and I don't
think it should be inferred that) it "is part of the data model".  Having
a json array was necessary to make the json valid (and really, it is there
because I copied and pasted the examples from
https://datatracker.ietf.org/doc/html/draft-ma-cdni-capabilities-09, which
was a proposed transport protocol implementation, and no one noticed until
now -- I also see an extra comma in the Section 5.3.1 example).  That
doesn't excuse the discrepancy, but the point is that it was not intended
to be proscriptive.  The intent of RFC8008 was only to define the base
object and the initial capabilities.  The transport protocol (e.g., alto)
was to define the encapsulating array that would contain the base objects
(e.g., “capabilities-with-footprints”), but RFC8008 is otherwise agnostic
to the naming of that array.

-- Kevin J. Ma

On Thu, Jul 15, 2021 at 3:10 AM Guillaume Bichot <
[email-masked]> wrote:

> Kevin, it is not about the transport protocol but the data model. Beyond
> the root object , there is the property “capabilities” that is defined
> nowhere but is part  of the data model (and used in all examples in
> RFC8008). It should be part of the RFC 8080 spec I think.
>
> At least the examples are confusing and the way Alto has implemented this confirms the problem. In Alto, they ignore that “capabilities”  property and somehow renamed it “capabilities-with-footprints”. Changing RFC8008 will make Alto not compatible and vice-versa.. This said, we do not use ALTO in SVA.
>
> In conclusion, we have the choice to either adopt the “capabilities”  property or the “capabilities-with-footprints” of the super object whatever it is.
>
> Guillaume
>
>
>
> Guillaume Bichot
>
> *From:* Kevin Ma <[email-masked]>
> *Sent:* Thursday, July 15, 2021 6:44 AM
> *To:* Guillaume Bichot <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [CDNi] Root object not defined in RFC8008: A bug ?
>
>
>
> Hi Guillaume,
>
>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-alto-cdni-request-routing-alto-16%23section-3.6&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C5f8c0508bad54e55df6d08d9474b39a7%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637619210687437646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Kwyafa01rXayWPXpsFzJaQgDHcf1dNLiUmc%2F2lel2a0%3D&reserved=0>
> ).
>
>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.broadpeak.tv%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C5f8c0508bad54e55df6d08d9474b39a7%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637619210687447601%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WWC5V831uhpgnYM2wFiO7iFdJ6jKAvoXrTss8ACceZI%3D&reserved=0>
>
>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fbroadpeak&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C5f8c0508bad54e55df6d08d9474b39a7%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637619210687447601%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sB3ZCj2xufpWXtjjOVwmzQUgkr3EF2a7IeU2pj2cm6k%3D&reserved=0>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fbroadpeak_2%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C5f8c0508bad54e55df6d08d9474b39a7%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637619210687457557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fQIPxEhD4Y%2B9oNLL6b06%2FfYeMfBPpa00hN9MdoBkanM%3D&reserved=0>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbroadpeak.tv%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C5f8c0508bad54e55df6d08d9474b39a7%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637619210687457557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iiRQUVNJJmQanas%2FN0Dw1ISvC7k7%2BUWQScOj%2FBKjp4I%3D&reserved=0>
>
>
>
>
>
>

---

From: Guillaume Bichot <[email-masked]>
Date: Mon, 26 Jul 2021 07:43:12 +0000

Thanks Kevin.
We have defined in SVA our own FCI API along with the data model including that encapsulating array.
Guillaume

Sent: Saturday, July 24, 2021 7:15 AM

Hi Guillaume,

> there is the property "capabilities" that is defined nowhere but is part  of the data model (and used in all examples in RFC8008)

  Again, I understand/agree that "capabilities" is not defined in RFC8008 but shows up in the examples -- but I don't think that implies (and I don't think it should be inferred that) it "is part of the data model".  Having a json array was necessary to make the json valid (and really, it is there because I copied and pasted the examples from https://datatracker.ietf.org/doc/html/draft-ma-cdni-capabilities-09<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ma-cdni-capabilities-09&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C73322cb8128d4ac7515d08d94e61ff75%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637627005077872699%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ryHJluE8wzxY6kQK17QU1FpbLbILPgLO1RkUED%2BpoV4%3D&reserved=0>, which was a proposed transport protocol implementation, and no one noticed until now -- I also see an extra comma in the Section 5.3.1 example).  That doesn't excuse the discrepancy, but the point is that it was not intended to be proscriptive.  The intent of RFC8008 was only to define the base object and the initial capabilities.  The transport protocol (e.g., alto) was to define the encapsulating array that would contain the base objects (e.g., "capabilities-with-footprints"), but RFC8008 is otherwise agnostic to the naming of that array.

-- Kevin J. Ma

On Thu, Jul 15, 2021 at 3:10 AM Guillaume Bichot <[email-masked]<mailto:[email-masked]>> wrote:
Kevin, it is not about the transport protocol but the data model. Beyond the root object , there is the property "capabilities" that is defined nowhere but is part  of the data model (and used in all examples in RFC8008). It should be part of the RFC 8080 spec I think.

Guillaume Bichot
Principal Engineer, Head of Exploration
broadpeak
m: +33 685 597 666    p: +33 222 740 350
[email-masked]<mailto:[email-masked]>

From: Kevin Ma <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 15, 2021 6:44 AM
To: Guillaume Bichot <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] Root object not defined in RFC8008: A bug ?

Hi Guillaume,

  The "official" transport for FCI is ALTO, and draft-ietf-alto-cdni-request-routing-alto defines the CDNIAdvertisementData object that encapsulates the BaseAdvertisementObjects (https://datatracker.ietf.org/doc/html/draft-ietf-alto-cdni-request-routing-alto-16#section-3.6<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-alto-cdni-request-routing-alto-16%23section-3.6&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C73322cb8128d4ac7515d08d94e61ff75%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637627005077872699%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=D5gMV9YmtDU0zF6UG7QTD7ScaEEbmh%2FvT%2FU0KwZbxBw%3D&reserved=0>).

thanx.

--  Kevin J. Ma

5.1.  Capabilities object

      Property: capabilities

...

What do you think?

Guillaume

Guillaume Bichot

m: +33 685 597 666    p: +33 222 740 350
[email-masked]<mailto:[email-masked]>
[Logo]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.broadpeak.tv%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C73322cb8128d4ac7515d08d94e61ff75%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637627005077882654%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ylwXarizRZrxUUzNoiCxffIkuyegi4XsiJwOV5k90F4%3D&reserved=0>

[twitter]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fbroadpeak&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C73322cb8128d4ac7515d08d94e61ff75%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637627005077882654%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bFQ42Gv%2F6xYrJQyecK8zOjVxPlsu9BtFjdLIAgkY1GE%3D&reserved=0>
[linkedin]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fbroadpeak_2%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C73322cb8128d4ac7515d08d94e61ff75%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637627005077892615%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2F50C2%2FCYZDqAQycSLDooDUn0GNUIJ%2B1R%2BzpQnpQwhbE%3D&reserved=0>
[website]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbroadpeak.tv%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C73322cb8128d4ac7515d08d94e61ff75%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637627005077892615%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=v4jRsMrZoETIK%2BBObbIsF6Ba7lCMEUQXM6H1IsHJVGo%3D&reserved=0>