Note: I hit ‘send’ too early, ugh. Please see the comments on the datatracker for the correct version.
Deb Cooley > On Apr 9, 2023, at 6:59 AM, Deb Cooley via Datatracker <[email protected]> > wrote: > > Reviewer: Deb Cooley > Review result: Not 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 last call comments. > > Document: draft-ietf-rtgwg-net2cloud-problem-statement-22 > Reviewer: Deb Cooley > Review Date: 2023-04-06 (early review) > > Please note that I know almost nothing about BGP, MPLS or routing. > > The summary of the review is > > Section 3.1, para 1, sentence 2: Grammar: 'with more variety of parties' could > be 'with a larger variety of parties.' > > Section 3.1, para 2, sentence 2: 'IP tunnels', does this imply IPSec? Or > something else? > > Section 3.1, para 3: By setting up default eBGP routes, these don't count as > routes from an external entity? The rest of the paragraph addresses the > handling of exceeding the maximum route threshold? But there appears to be an > option to keep the BGP session? This paragraph is confusing. > > Section 3.2, paragraph 2: IGP? AS? I can't tell what this is trying to say. > > Section 3.2, paragraph 3: If there is a site failure, how is the Cloud GW > 'running fine'? Is this GW using a different site? BFD? > > Section 3.2: Para 1 states why a site might go down. Para 2-6 outline the > routing (?) issues that occur when a site goes down. I think these could be > better organized. Only the last para suggests mitigations. > > Section 3.3 I'm not an expert, but isn't this an issue to any routing > scenario? > Can this be combined with Section 3.6? > > Section 3.4, para 3, item 1: Is this a problem? Or a feature? If it is a > problem, can you say why? > > Section 3.5: I would suggest moving this to Section 7. There are a couple of > mitigations listed - anti-DDOS, DTLS, IPSec, monitoring. > > Section 3.6, last paragraph: A globally unique name won't 'resolve the same > way from every perspective'? Other than being restricted (previous > paragraph), > what does this mean? If this is covered in the previous para, I would > recommend > deleting the phrase. > > Stopped at Section 4. > > > > _______________________________________________ > secdir mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/secdir > wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
