Re: [CDNi] Roman Danyliw's No Objection on draft-ietf-cdni-additional-footprint-types-07: (with COMMENT)

[Nir Sopher <[e-mail]>]

Hi  Roman,
Thank you very much for the comments.
See reply inline.
Thanks,
Sanjay and Nir

On Sat, Dec 31, 2022 at 12:03 AM Roman Danyliw via Datatracker <
[e-mail]> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-cdni-additional-footprint-types-07: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
>
> https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you to Daniel Migault for the SECDIR review.
>
> ** Section 2.1.1.1.  Editorial.
>
>    An [ISO3166-2] code in lowercase.  Each code consists of two parts
>    separated by a hyphen.  The first part is the [ISO3166-1] code of the
>    country.  The second part is a string of up to three alphanumeric
>    characters.
>
> ISO3166-2 already defines the format.  To make that clear, consider s/The
> first
> part is/Per [ISO3166-2], the first part is/
>
Addressed in v08

>
> ** Section 2.2.  Typo. “syntextual restrication”.  I’m not sure what to
> replace
> both of these words with.  Is it “syntactic restriction”?
>
Fixed (v08)

>
> ** Section 5.  Editorial.


>    More specifically, the use of "subdivisioncode" footprint type,
>    introduces a higher level of granularity into the published dCDN
>    Footprint.  Therefore, to meet confidentiality requirements ...
>
> It does not follow for my why a more specific sub-division code (sentence
> one)
> suggests confidentiality requirements (sentence two).
>
Agreed.
The sentence was not adding anything new here. It was mostly confusing and
omitted on v08

>
> ** Section 5.  In describing the CDNI Metadata Objective Model, Section 3
> of
> RFC8006 hints at the uCDN expressing geo-blocking rules.  In addition to
> the
> intended use cases suggested in Section 1 of this document, is this higher
> resolution geographic metadata going to provide primitives that can express
> more selective filtering of content in the boundaries of a country?  While
> this
> dual use may not avoidable, should this be acknowledged?
>

As this document (as well as the FCI) deals with dCDN signaling
capabilities to the uCDN,
This document provides for downstream CDN to advertise footprint and
capability for a given geography, but it is out of scope for determining
what content is served and where. This is determined upstream by either an
upstream CDN or a CP. Therefore in our view it is not necessary to
incorporate instruction for geo blocking.