Hi Klaas and Qin, Thanks for the review and suggestions. See my comments inline.
Thanks, Jensen On Tue, Nov 30, 2021 at 12:59 AM Klaas Wierenga <kl...@wierenga.net> wrote: > Hi Qin, > > > On 24 Nov 2021, at 14:07, Qin Wu <bill...@huawei.com> wrote: > > > > Hi, Klaas: > > -----邮件原件----- > > 发件人: Klaas Wierenga via Datatracker [mailto:nore...@ietf.org] > > 发送时间: 2021年11月24日 17:24 > > 收件人: sec...@ietf.org > > 抄送: alto@ietf.org; > draft-ietf-alto-cdni-request-routing-alto....@ietf.org; last-c...@ietf.org > > 主题: Secdir last call review of > draft-ietf-alto-cdni-request-routing-alto-17 > > > > Reviewer: Klaas Wierenga > > Review result: Has Issues > > > > Hi, > > > > I found 1 nit and one more substantial issue > > > > - the abstract says: > > > > OLD > > RFC 8008 defines precisely the semantics of FCI and provides guidelines > on the FCI protocol, but the exact protocol is specified. > > > > I think it should read > > > > NEW > > RFC 8008 defines precisely the semantics of FCI and provides guidelines > on the FCI protocol, but the exact protocol is not specified. > [Jensen] Thanks for pointing it out. The authors will fix it in the next revision. > > > > - A bigger problem I have is with the Security Considerations > > > > You state "In the context of CDNI Advertisement, additional security > > considerations should be included as follows:", you then list a set of > > concerns, and then write: "Although protection strategies as described > in > > Section 15 of [RFC7285] should be applied to address aforementioned > security > > and privacy considerations, one additional information leakage risk > > introduced by this document could not be addressed by these > strategies. " > > > > So are they ADDITIONAL or were they ALREADY ADRESSED in RFC7285? Do you > want to call the ones you list out as specifically relevant for this > use-case? Please be clear why you list them here. And if they are NOT > sufficiently addressed yet, you need to address them here. > > [Qin Wu] : I believe these ADDITIONAL security has already been > ADDRESSED by protection strategies proposed in RFC7285, but there is one > exception case, i.e.," one additional information leakage risk > > introduced by this document could not be addressed by these > strategies." > > Maybe the first paragraph and the second paragraph lack a good > connection link, I would propose to make the following change: > > OLD TEXT: > > " > > In the context of CDNI Advertisement, additional security > > considerations should be included as follows: > > " > > NEW TEXT: > > " > > In the context of CDNI Advertisement, the following security > > issues need to be considered as follows: > > " > [Jensen] Qin's proposed text looks good to me. The four bullet items are risk scenarios that are not listed in RFC7285 but can be addressed by corresponding protection strategies proposed by RFC7285. Only the "one additional information leakage risk" in the next paragraph is the exception that cannot be addressed by RFC7285. > > Would it be clearer if you would write s/additional/specifically ? It > seems you want to call out the one as of particular importance? > [Jensen] Sounds good to me. > > > For the additional risk of leaking info from one uCDN to another uCDN it > is unclear to me whether the intended mitigation is meant as normative > (SHOULD instead of should) and I am curious why you don't make it a MUST. > > [Qin Wu] I have no strong opinion on what language should be used, but I > agree SHOULD is better than should. > > Perfect. > [Jensen] For my understanding, the protection strategy is just an optional feature that is recommended to be implemented, but not a mandatory-to-implement feature. All the protection strategies described in RFC7285 also use "should" not "must". But I also agree "SHOULD" is better. > > Klaas > > > > > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
