Last Call Review of draft-ietf-rtgwg-net2cloud-problem-statement-41
review-ietf-rtgwg-net2cloud-problem-statement-41-dnsdir-lc-tale-2024-09-08-00

dnsdir review of draft-ietf-rtgwg-net2cloud-problem-statement.

Looking at this page:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/
I see a dnsdir last call review due now (well, five days ago), as well
as secdir, opsdir, and rtgdir "early" reviews on a 41 version document
due a month from now.  I'm not really quite sure what to make of that,
but someone probably ought to have a look.

dnsdir previously reviewed this a year and a half ago.  I generally
concur with Florian Ober's assessment, that the document is
substantially ready with the edits that were made in response to his
initial review.

Nit: Since the writing of this document has proceeded into 2024 and
the problems it describes are still relevant, perhaps "(2023)" should
be "(2024)".

Even more minor nit: the use of four parentheticals in a three
sentence abstract is a bit distracting.  They could be adjusted to
fewer parentheticals without loss of meaning.

Section 3 deals with the DNS issues of data center traffic management.
It is sound enough in its analysis as far as providing the basis of a
problem statement, since it is not attempting to propose the details
of a new protocol but just descriptively identifying the landscape.

While I might have some minor stylistic quibbles regarding issues of
capitalization and so on, and some minor proofreading issues, that's
not for me to hold you up on.  Even the nits I mentioned above aren't
meaningful enough to demand edits before it proceeds to the next
chapter of its editorial life, so that's why I've given it just a
Ready rather than Ready w/nits.

The one possibly minor thing I might have referenced is that there are
DNS providers who do attempt to deal with issues like the one
referenced here:

     - Inflexible traffic control:
        The Local DNS resolver becomes the unit of traffic management.
        This requires DNS to receive periodic updates of the network
        condition, which is difficult.

It isn't wrong, but it feels a bit peculiar to overlook that although
it is difficult, there are existing systems out there that try to
address it.  I wouldn't say much though, just that proprietary systems
exist and therefore can also be problematic in their own way because
of how they create vendor stickiness.