Florian, Can you please let us know if you have further comments to the revision that have addressed your previous comments? https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/
If you are satisfied with the revision, can you please change your review status to READY? Thank you Linda _____________________________________________ From: Linda Dunbar Sent: Friday, March 10, 2023 5:32 AM To: Florian Obser <[email protected]>; [email protected] Cc: [email protected]; [email protected] Subject: RE: Dnsdir early review of draft-ietf-rtgwg-net2cloud-problem-statement-20 Florian, Thank you very much for the review and the suggestions. All your suggestions have been reflected in the latest version: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/ . Linda -----Original Message----- From: Florian Obser via Datatracker <[email protected]<mailto:[email protected]>> Sent: Tuesday, March 7, 2023 12:50 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Dnsdir early review of draft-ietf-rtgwg-net2cloud-problem-statement-20 Reviewer: Florian Obser Review result: Ready with Issues This is an early review of draft-ietf-rtgwg-net2cloud-problem-statement I'm the assigned reviewer of the DNS Directorate for this draft. The DNS Directorate seeks to review all DNS or DNS-related drafts as they pass through IETF last call and IESG review, and on special request for early review. For more information about the DNS Directorate, please see https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.ietf.org%2Fen%2Fgroup%2Fdnsdir&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cced6174457bb41e3332208db1f3cb79f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638138117868017502%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6mEfbNxzTPZlswhA86unZK8UfIIay9QeVHyANXQxaY0%3D&reserved=0 The draft discusses DNS topics in two sections: 3.3 and 3.6 3.3 Optimal Paths to Cloud DC locations by responding a FQDN should be by responding to a FQDN [Linda] corrected. - Client can cache results indefinitely I think it's worth while to point out that this is not a feature of DNS but because of a misbehaving client. How about - Misbehaving client can cache results indefinitely [Linda] changed to your suggested word. - Client may not receive service even though there are servers available (before cache timeout) in other Cloud DCs. "cache timeout" is a weird term, I guess the intent is not a network timeout while talking to a caching resolver but the time until an answer is evicted from the cache of the resolver. How about: - Client may not receive service even though there are servers available in other Cloud DCs because the failing IP address is still cached in the DNS resolver and has not expired yet. [Linda] Yes, your description is much more clear. 3.6 DNS Practices for Hybrid Workloads .cloud is a generic TLD in the root zone, its a poor example for an internal name. Or a very good example, but it's not spelled out that it will lead to collisions with public names. It might be better to use .internal which is in use in public clouds but not a gTLD. furthermore, addressing the reader with "you" sounds odd: However, even with carefully managed policies and configurations, collisions can still occur. If you use an internal name like .cloud and then want your services to be available via or within some other cloud provider which also uses .cloud, then collisions might occur. Therefore, it is better to use the global domain name even when an organization does not make all its namespace globally resolvable. An organization's globally unique DNS can include subdomains that cannot be resolved outside certain restricted paths, zones that resolve differently based on the origin of the query, and zones that resolve the same globally for all queries from any source. how about: However, even with carefully managed policies and configurations, collisions can still occur. If an organization uses an internal name like .internal and then want their services to be available via or within some other cloud provider which also uses .internal, then collisions might occur. Therefore, it is better to use the global domain name even when an organization does not make all its namespace globally resolvable. An organization's globally unique DNS can include subdomains that cannot be resolved outside certain restricted paths, zones that resolve differently based on the origin of the query, and zones that resolve the same globally for all queries from any source. "you" is also used in 3.8 and 4.2 which might be worthwhile to change, too. [Linda] All changed per your suggestion. The last paragraph of 3.6 is excellent advice. The reviewer only skimmed the rest of the document, the following nits where spotted: 1. Introduction third parties Cloud Operators should be third party Cloud Operators 3.2 Site failures and Methods to Minimize Impacts cyber threats attacks should be cyber threat attacks 3.4. Network Issues for 5G Edge Clouds and Mitigation Methods this is formatted weirdly: 1) The difference of routing distances to multiple server instances in different edge Cloud is relatively small. 2) Capacity status at the Edge Cloud DC might play a bigger role for E2E performance. 3) Source (UEs) can ingress from different LDN Ingress routers due to mobility. in case the data tracker messes up the formatting, there is a lot of white space between "1)" and "The difference.." [Linda] cause by my text conversion tool. 3.5. Security Issues and Methods to Minimize impacts again, lots of white space: cloud edge resources. To mitigate such 4.2. Inter-Cloud Connection lots of white space a) Utilize Cloud DC provided... [Linda] Thanks for catching all of those.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
