Re: [CDNi] [E] draft-ietf-cdni-additional-footprint-types-01.txt

[Benson Muite <[e-mail]>]

Hi Kevin,

ISO 3166-2 is nice, but there are no sub divisions below it, likely 
partly because there are so many country specific variations.  Many 
states in the USA have similar land areas and populations to countries 
in Europe.

 From a practical point of view, consumer facing ISPs will either have 
cables to end users in certain regions, or cell towers in certain 
regions with particular capabilities.  Thus, if they are going to give 
quality of service assurance guarantees, ISO 3166-2 regions will be too 
large.  From deploying and using video conferencing platforms, the 
current end user tool for testing quality of service is using ping and 
measuring upload and download speeds.  Knowing that an ISP can provide 
high quality of service within a particular region would be helpful for 
end users and broadcasters.

Regards,
Benson

On 7/4/22 19:51, Kevin Ma wrote:
> Hi Benson,
> 
>    Thanks for the pointer!  In my past experience, a lot of the 
> contractual obligations for content serving tended to revolve around 
> political subdivisions (for better or worse), so I can see the immediate 
> use case for ISO 3166-2.  Though I've heard of trying to do more 
> granular geo-fencing in local markets, I'm not sure how prevalent those 
> are these days.  When looking at a use case, it is certainly helpful if 
> technical solutions (as you point out) exist, but I'd also look at ease 
> of use and adoption by end users.  Again, I don't have insight into how 
> broadly coordinate-based geo-fencing is used or how much demand there is 
> for it today or on the horizon.  My concern is that: though 
> coordinate-based geo-fencing is a superset, as you point out, if the 
> increased complexity of managing the official coordinate set definitions 
> and translating them back to the business terms is too high, then the 
> solution may not be useful.  I don't want to discount a viable 
> alternative, but I also don't want to over-engineer a solution if the 
> proposed solution meets our needs.
> 
>    I look to others who may have more real world use case knowledge here 
> to weigh in on the merits of the coordinate-based geo-fencing alternative?
> 
> thanx!
> 
> --  Kevin J. Ma
> 
> 
> On Mon, Jul 4, 2022 at 12:31 PM Benson Muite <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     An openly accessible version of the standard is available at
>     https://docs.ogc.org/as/18-005r5/18-005r5.html
>     <https://docs.ogc.org/as/18-005r5/18-005r5.html>
> 
>     On 7/4/22 18:25, Benson Muite wrote:
>      > Hi Kevin and Sanjay,
>      >
>      > Thanks for the feedback and takig this into consideration.  Sorry
>     missed
>      > your first message Sanjay.
>      >
>      > For your use case of distribution from an upstream CDN to ISP
>     caches,
>      > this seems ok.
>      >
>      > For distribution from ISP caches, ISO 3166-2 are political
>     subdivisions
>      > of a country.  Many ISPs will give information on particular
>      > neighborhoods they serve, so it is possible to be much more
>     precise on
>      > their reach than is possible from ISO 3166-2. There will be many
>     cases
>      > where a full subdivision will not be reachable - I expect some
>     regions
>      > in Alaska would fit in this category, in addition to many regions in
>      > Africa and possibly some regions in Russia and Australia.
>      >
>      >
>      > There is a standard for earth based coordinates [1], and an
>      > implementation[2]. This may give more flexibility since it can also
>      > describe ISO 3166-2 regions.
>      >
>      > Benson
>      >
>      > [1] https://www.iso.org/standard/74039.html
>     <https://www.iso.org/standard/74039.html>
>      > [2] https://www.osgeo.org/projects/proj/
>     <https://www.osgeo.org/projects/proj/>
>      >
>      > On 7/4/22 17:18, Kevin Ma wrote:
>      >> Hi Benson/Sanjay,
>      >>
>      >>    (As chair) I think if there is a strong use case for a more
>      >> detailed closed-polygon approach, it could be considered.  It could
>      >> also be a separate draft if it is not yet fully fleshed out.  Given
>      >> the SVAs specific use case, and the simplicity of the proposal, I
>      >> would hesitate to add more complexity without a real world
>      >> requirement.  Again, nothing prevents a subsequent draft adding
>      >> another footprint type if it turns out we need more granularity.
>      >>
>      >>    Do we think we can live with the current proposal for now?
>      >>
>      >> thanx!
>      >>
>      >> --  Kevin J. Ma
>      >>
>      >>
>      >> On Thu, Jun 30, 2022 at 9:12 AM Mishra, Sanjay
>      >> <sanjay.mishra=[e-mail]
>     <mailto:[e-mail]>
>      >> <mailto:[e-mail]
>     <mailto:[e-mail]>>> wrote:
>      >>
>      >>     Hi Benson -
>      >>
>      >>     (speaking as a co-author of the document ->
>      >>
>      >>
>     https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/
>     <https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/>
> 
>      >>
>      >>
>      >>
>     <https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/
>     <https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/>>)
> 
>      >>
>      >>
>      >>     The scope of the current draft is intentionally limited to a use
>      >>     case that allows delegation from an upstream CDN (a CDN or a
>     content
>      >>     provider) to be able to delegate to a downstream CDN
>     (specifically,
>      >>     ISP hosted caches) for content distribution to the eyeballs. The
>      >>     particular use case focused on delegation that allowed
>     delegation
>      >>     such as ASN+State, and for the purposes of reaching out to the
>      >>     larger geographic area, this level of granularity was
>     implemented
>      >>     and tested.
>      >>
>      >>     Much of the work and implementation has been done within the
>     open
>      >>     caching working group(1) of the streaming Video Alliance(2).
>      >>
>      >>     My sense is to keep the scope to what has been verifiably
>      >> implemented.
>      >>
>      >>     Thanks
>      >>     Sanjay
>      >>
>      >>     1. https://opencaching.streamingvideoalliance.org/
>     <https://opencaching.streamingvideoalliance.org/>
>      >>     <https://opencaching.streamingvideoalliance.org/
>     <https://opencaching.streamingvideoalliance.org/>>
>      >>     2. https://www.streamingvideoalliance.org/
>     <https://www.streamingvideoalliance.org/>
>      >>     <https://www.streamingvideoalliance.org/
>     <https://www.streamingvideoalliance.org/>>
>      >>
>      >>
>      >>
>      >>     On Tue, Mar 22, 2022 at 2:47 PM Benson Muite
>      >>     <[e-mail]
>     <mailto:[e-mail]>
>     <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      >> wrote:
>      >>
>      >>         Hi,
>      >>
>      >>         This is a helpful addition.  However, the specification may
>      >>         still be too
>      >>         broad, in particular for sparsely populated regions
>     where one
>      >>         might be
>      >>         able to guarantee access to a single town or city in an
>     ISO3166-2
>      >>         region, but not to other settlements in the region.  The
>     original
>      >>         specification does allow for geographical coordinates.
>     It may be
>      >>         helpful
>      >>         to also allow optional specification of a closed polygon
>     using
>      >>         latitude
>      >>         and longitude coordinates. One could take inspiration
>     from the
>      >>         shapefile
>      >>         specification which uses a bounding box, and an inscribed
>      >>         polygon[1].
>      >>
>      >>         [1]
>      >>
>      >>
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.esri.com_content_dam_esrisites_sitecore-2Darchive_Files_Pdfs_library_whitepapers_pdfs_shapefile.pdf&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=htQEgl59hF4CCQp8CjJ4ejkEnghLcOlLT90ueF2UV_dBw7MO8aJQ2ySWADGFLi2V&s=hhmf2D26bLIYC7KYgYKYwqnIQG1ybUySFg9q-_n5X2A&e=
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.esri.com_content_dam_esrisites_sitecore-2Darchive_Files_Pdfs_library_whitepapers_pdfs_shapefile.pdf&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=htQEgl59hF4CCQp8CjJ4ejkEnghLcOlLT90ueF2UV_dBw7MO8aJQ2ySWADGFLi2V&s=hhmf2D26bLIYC7KYgYKYwqnIQG1ybUySFg9q-_n5X2A&e=>
> 
>      >>
>      >>
>      >>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.esri.com_content_dam_esrisites_sitecore-2Darchive_Files_Pdfs_library_whitepapers_pdfs_shapefile.pdf&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=htQEgl59hF4CCQp8CjJ4ejkEnghLcOlLT90ueF2UV_dBw7MO8aJQ2ySWADGFLi2V&s=hhmf2D26bLIYC7KYgYKYwqnIQG1ybUySFg9q-_n5X2A&e=
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.esri.com_content_dam_esrisites_sitecore-2Darchive_Files_Pdfs_library_whitepapers_pdfs_shapefile.pdf&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=htQEgl59hF4CCQp8CjJ4ejkEnghLcOlLT90ueF2UV_dBw7MO8aJQ2ySWADGFLi2V&s=hhmf2D26bLIYC7KYgYKYwqnIQG1ybUySFg9q-_n5X2A&e=>>
> 
>      >>
>      >>
>      >>
>      >>         _______________________________________________
>      >>         CDNi mailing list
>      >> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >>
>      >>
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_cdni&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=htQEgl59hF4CCQp8CjJ4ejkEnghLcOlLT90ueF2UV_dBw7MO8aJQ2ySWADGFLi2V&s=41guO0KJiN_jm6BiyF39vK_EHWUBpqu8J4IPosCdyQQ&e=
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_cdni&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=htQEgl59hF4CCQp8CjJ4ejkEnghLcOlLT90ueF2UV_dBw7MO8aJQ2ySWADGFLi2V&s=41guO0KJiN_jm6BiyF39vK_EHWUBpqu8J4IPosCdyQQ&e=>
> 
>      >>
>      >>
>      >>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_cdni&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=htQEgl59hF4CCQp8CjJ4ejkEnghLcOlLT90ueF2UV_dBw7MO8aJQ2ySWADGFLi2V&s=41guO0KJiN_jm6BiyF39vK_EHWUBpqu8J4IPosCdyQQ&e=
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_cdni&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=htQEgl59hF4CCQp8CjJ4ejkEnghLcOlLT90ueF2UV_dBw7MO8aJQ2ySWADGFLi2V&s=41guO0KJiN_jm6BiyF39vK_EHWUBpqu8J4IPosCdyQQ&e=>>
> 
>      >>
>      >>
>      >>
>      >>     _______________________________________________
>      >>     CDNi mailing list
>      >> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >> https://www.ietf.org/mailman/listinfo/cdni
>     <https://www.ietf.org/mailman/listinfo/cdni>
>      >>     <https://www.ietf.org/mailman/listinfo/cdni
>     <https://www.ietf.org/mailman/listinfo/cdni>>
>      >>
>      >
>      > _______________________________________________
>      > CDNi mailing list
>      > [e-mail] <mailto:[e-mail]>
>      > https://www.ietf.org/mailman/listinfo/cdni
>     <https://www.ietf.org/mailman/listinfo/cdni>
>