Thanks for the clarifications.
Yours ,
Daniel
On Tue, Dec 13, 2022 at 3:57 PM Nir Sopher <nirsopher@xxxxxxxxx> wrote:
Hi Daniel,Thank you for the deep dive into the concepts and incentives of the draft.Per your remarks, please see our comments inline :)
Cheers,Sanjay and NirOn Sat, Dec 10, 2022 at 5:05 PM Daniel Migault via Datatracker <noreply@xxxxxxxx> wrote:Reviewer: Daniel Migault
Review result: Ready
Hi,
Reviewer: Daniel Migault
Review result: Ready
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other
The comment below mostly reflects what raised my curiosity while reading the
document. I do not see any of these comments requires some changes to the
document.
While reading the document I was wondering what could be the reason for
advertising ca-ns and us-ny. Note that whatever the response is, there is no
need to change the document. From my point of view, I imagined that subdivision
code would be mostly used to characterize a geographic zone that is served by a
CDN and so that expected codes would be neighbor areas. The example takes ca-ns
and us-ny which I do not see as neighbors, at least geographically speaking. I
know we can always find a case, but I am wondering if it is expected to be
common to have some non neighbor subdivisions being advertised and why. One
reason could be that geographic neighborhood and networking neighborhood may
also be distinct and I would be curious to understand if that is the reason and
how often it is expected to happen. To be clear, I am fine if the subdivision
code has just been taken (pseudo) randomly for example.Indeed. A geographical proximity is expected to be the common case.The reason we presented ca-ns and us-ny was to give an example for 2 types of subdivisions - a Province in Canada vs. a state in the US.But now that you bring it up, we see it can confuse the reader.To make it more intuitive to the reader, we will change the example to reflect the geographical proximity, presenting for example NY and NJ or NY and Ontario.
Thanks for the clarification. NY and Ontario is probably the best choice ;-)
The Union data type is mentioned as overcoming the limitation of narrowing
capability. I think the text is nice saying that narrowing does not work for
what we do, but overall I do see the need to have union as a completely
separate need from the need to narrow. In other words, I do not see the
justification as something needed. My perception is that we were able to have
AND and Union enables to have OR.
If my understanding is correct, I have the impression that there is an
alternative way to achieve OR which would consist of having different separate
advertisements. Not being an expert in CDNI, what I have in mind is that a dCDN
may send one advertisement with a union or may make multiple advertisements (1
for each member of the union). I am not challenging here the need for a union
as I am convinced it is needed - or will be needed at some point. What I would
like to understand is if multiple advertisements could effectively be
considered as an alternative to the union. If that is correct, I would be
interested to briefly understand the pro/cons of each alternative. I suspect
this mostly an operational advantage, but I am curious to learn a bit more on
it.There are a few reasons for using union. Indeed there is an operational efficiency in joiningAdditionally, there are more substantive uses of union, such as in cases where the advertised capability refers to a fixed commodity (e.g. capacity).For example, in the case a dCDN advertises its "capacity" capability, which may apply for an overall set of IPs, from both IPv4 and IPv6.The union allows us to be unambiguous - avoiding overbooking of "capacity units", on the one hand, as well as utilizing the advertised capacity efficiently (without arbitrarily splitting it) on the other.
Thanks for the clarification, that makes complete sense.
The SUBDIVISION Domain was not entirely clear to me, but I suspect this
connects the newly defined footprint type to the more generic framework.
The main security consideration I have regarding the footprint type is the
ability to prove that the dCDN is legitimate for announcing such capabilities.
Typically, I am wondering if there is any way to prevent a CDN to advertise
capabilities in Australia for example - while he is not serving that region ?
Note that we generic and so, is likely to be already addressed at a higher
level. My impression is that the model is that one has to trust the
advertisement, and so only consider those of trusted CDNs. I am wondering if
there are any practical ways to evaluate the trustworthiness related to the
subdivision.
Indeed, there is no mechanism preventing dCDN from publishing capabilities for IPs they do not own / cannot really serve.This issue was also discussed in RFC 8008 section 2.4, which mostly refers to resolution of the issue at the business/contractual level.They also point to the option to make the Footprint verifiable, mostly out-of-band (non realtime).There is very little to know incentive for a dCDN to cheat, as RFC 8008 states that it may "negatively affect the long-term business relationship".
I see.
_______________________________________________Yours,
Daniel
_______________________________________________
CDNi mailing list
CDNi@xxxxxxxx
https://www.ietf.org/mailman/listinfo/cdni
CDNi mailing list
CDNi@xxxxxxxx
https://www.ietf.org/mailman/listinfo/cdni
Daniel Migault
Ericsson
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
