Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-additional-footprint-types-00.txt

From: Kevin Ma <[email-masked]>
Date: Fri, 11 Feb 2022 00:25:27 -0500

Hi All,

  (As Chair) Having confirmed adoption of the footprint registration draft
at the last meeting, I believe we all agreed that the contents are pretty
straightforward and useful.  I don't see much additional work being
required before issuing a WGLC.  As is our custom, I have done a
preliminary shepherd review of the doc (Nir, please see my comments
below).  I encourage everyone to please give the draft a read and send any
questions, concerns, or suggestions to the list.  We will otherwise plan to
issue a WGLC once the preliminary review comments have been addressed.

thanx!

--  Kevin J. Ma

comments:
---------

general:
- "e.g." -> "e.g.,"

abstract:
- "supplements to the" -> "supplements the"
- "as part of the Footprint & Capabilities Advertisement interface (FCI)
defined in RFC 8008" -> "as part of the Footprint & Capabilities
Advertisement interface (FCI) defined in RFC 8008 or the Metadata interface
(MI) defined in RFC 8006"

section 1:
- "registers CDNI Footprint and Capabilities objects[RFC8008]" ->
"registers CDNI Footprint Types [RFC8006]"
- "Footprints Types.  E.g." -> "Footprints Types, e.g.,"

section 2:
- "For consistency, this document follows the CDNI notation of uCDN for
(the commercial CDN) and dCDN (the ISP caching layer)." -> remove?  this is
redundant (already stated in section 1)?

section 2.1:
- "Here we define" -> "Herein is defined"

section 2.1.2:
- "Below is an adjustment for the example in Section 2.1.1, now embedding a
footprint object of type \"SubdivisionCode\"." -> "Below is an example
using footprint objects of type \"SubdivisionCode\"." (section 2.1.1 of
this draft does not make sense as a reference?)
- "in Nova-Scotia province" -> "in the Nova-Scotia province"

section 2.2:
- "Meaning," -> "This implies that" ?
- "define an FCI Capability Advertisement Object footprint constraints" ->
"define FCI Capability Advertisement Object footprint constraints"
- "in order" -> remove?
- "results with an" -> "results in an"
- "limitation, and" -> "limitation and"
- "constraints that matches" -> "constraints that match"
- "we introduce below" -> "below is introduced"

section 2.2.1:
- "It includes a footprint-type property and a footprint-value array
values" -> "The footprint-value for a FootprintUnion object is an array of
Footprint objects, where the Footprint objects may be of any Footprint Type
other than FootprintUnion." we probably don't want to nest footprintunion?
 do we want to allow duplicate type entries (e.g., multiple ipv4cidrs);
it's inefficient, but doesn't break anything?

section 2.2.2:
- "Below is an adjustment for the example in Section 2.2.1, now embedding a
footprint object of type \"footprintunion\"." -> "Below is an example using
a footprint object of type \"footprintunion\"." (section 2.2.1 of this
draft does not make sense as a reference?)
- "An additional example is the collection" -> "Below is an additional
example for the union" ?
- ", as well as Nova-Scotia province" -> "and the Nova-Scotia province"

section 3.1:
- "As described in section 7.2 of [RFC8006] , the \"CDNI Metadata Footprint
Types\" subregistry was created" -> "Section 7.2 of [RFC8006] creates the
\"CDNI Metadata Footprint Types\" subregistry"
- "The created namespace defines the valid values for Footprint Object
Types, and is already populated with the types described in Section 4.2.2.2
of [RFC8006] ."  remove?  unnecessary information
- "two additional footprint type as" -> "two additional Footprint Types"
- "Footprint Object as specified in [RFC8006]" -> "Footprint Type Union" ?

section 4:
- "CDNI Request Routing: Footprint and Capabilities Semantics" -> "CDNI
Metadata interface and the CDNI Request Routing: Footprint and Capabilities
Semantics"
- We should also add a Privacy section that acknowledges the potential
leakage of private network topology information when providing footprint
information, but note that this document only defines the datatype and not
the transport, and that RFC8006 and RFC8008 require interface
implementations implement confidentiality and authentication to prevent
such data loss.

section 6.1:
- do we really need terminology references to RFC8007 and RFC8804 ?

section 6.2:
- do we really need a terminology reference to RFC6707 ?

On Thu, Nov 11, 2021 at 4:29 PM <[email-masked]> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Content Delivery Networks Interconnection
> WG of the IETF.
>
>         Title           : Content Delivery Network Interconnection (CDNI)
> Footprint Types: Subdivision Code and Union
>         Authors         : Nir B. Sopher
>                           Sanjay Mishra
>         Filename        : draft-ietf-cdni-additional-footprint-types-00.txt
>         Pages           : 11
>         Date            : 2021-11-11
>
> Abstract:
>    Open Caching architecture is a use case of Content Delivery Networks
>    Interconnection (CDNI) in which the commercial Content Delivery
>    Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer
>    serves as the downstream CDN (dCDN).  This document supplements to
>    the CDNI Metadata Footprint Types defined in RFC 8006.  The Footprint
>    Types defined in this document can be used for Footprint objects as
>    part of the Footprint & Capabilities Advertisement interface (FCI)
>    defined in RFC 8008.  The defined Footprint Types are derived from
>    requirements raised by Open Caching but are also applicable to CDNI
>    use cases in general.
>
>
> The IETF datatracker status page for this draft is:
>
> https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/
>
> There is also an htmlized version available at:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-cdni-additional-footprint-types-00
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>

---

From: Nir Sopher <[email-masked]>
Date: Mon, 14 Feb 2022 02:18:39 +0200

Hi Kevin,
Many thanks for the shepherd review.
I have integrated most of the comments.
Inline I relate to comments which were not taken as is.
Thanks again,
Nir

> (MI) defined in RFC 8006"
 [NirS] Done but I changed the order: first the MI and afterwards the FCI

> - "Below is an adjustment for the example in Section 2.1.1, now embedding
> a footprint object of type \"SubdivisionCode\"." -> "Below is an example
[NirS]  Duplicate type entries do not break anything, and I believe that
should be allowed for convenience (e.g., when joining together
subdivisions from Canada and the US, it might be more convenient to split
them into 2 objects by their country).
[NirS]  I would still want to further think about the nested
footprint unions.

>
> section 2.2.2:
> - "Below is an adjustment for the example in Section 2.2.1, now embedding
> a footprint object of type \"footprintunion\"." -> "Below is an example
> using a footprint object of type \"footprintunion\"." (section 2.2.1 of
[NirS] Paragraph rephrase:
The footprint union also allows to compose a countrycode and
subdivisioncode based footprint objects. In the example below we create a
constraint covering autonomous system 64496 within the US (ISO [ISO3166- 1]
alpha-2 code "US") and the Nova-Scotia province of Canada (ISO [ISO3166-2]
code "CA-NS").

>
> section 3.1:
> - "As described in section 7.2 of [RFC8006] , the \"CDNI Metadata
> Footprint Types\" subregistry was created" -> "Section 7.2 of [RFC8006]
> creates the \"CDNI Metadata Footprint Types\" subregistry"
[NirS] I believe it should stay as is: where the format of the elements
listed is described - similar to the table in RFC 8006
<https://datatracker.ietf.org/doc/html/rfc8006#section-7.2>. What do you
think?
[NirS] I also modified the description on the FCI.subdivision footprint type:
"ISO 3166-2 Subdivision Code: An alpha-2 ISO 3166-1 Country Code, followed
by a separator and up to three alphanumeric characters"

> implementations implement confidentiality and authentication to prevent
[NirS] Still TBD

> - do we really need a terminology reference to RFC6707 ?
[NirS] I think this is where uCDN and dCDN are first defined (RRFC 7336
also points to it in this context) .
>> This draft is a work item of the Content Delivery Networks
>> Interconnection WG of the IETF.
>>
>>         Filename        :
>> draft-ietf-cdni-additional-footprint-types-00.txt
>>         Pages           : 11
>>         Date            : 2021-11-11
>>
>> Abstract: