Early Review of draft-ietf-iotops-iot-dns-guidelines-04
review-ietf-iotops-iot-dns-guidelines-04-iotdir-early-berger-2026-08-10-00

Hi,

I’ve been assigned the IoT directorate reviewer for this document.  I think the
document is close. I was torn whether to mark this document “Almost Ready” vs
“Ready with Issues” but decided to go with the former even though my first
general comment may be considered stylistic. My other comments should be easily
addressed prior to publication.

General:

- As I read it, there are three target audiences for this document: IoT device
manufacturers; manufacturers of DNS servers used by IoT devices; and network
operators that deploy IoT   devices.  Guidelines operators are unambiguous, as
they are limited to section 5. I found it harder to follow which guidelines
apply to remaining two.

As far as I can tell, Section 3 “Guidance for IoT Device Manufacturers”
actually covers both IoT Devices and DNS Servers used by IoT devices.  The
document states that IoT Devices are also referred to as “Stub Resolvers” and
“Resolver refers to the DNS server used by the IoT device”.  The document then
goes on to use other terms such as “manufacturers” and “device” without making
it clear if such refers to both or just one.  (It seems to me that sometimes it
means one and sometimes it means both, based on context).

I recommend that guidelines to each target audience be clearly labeled, either
in separate sections as was done in section 5, or in separate sub-sections
after introducing a common topic. For example, Section 3.3 could introduce the
topic of TTL Handling and new Sections 3.3.1 could cover IoT Devices and 3.3.2
could cover DNS Servers. I also recommend sticking to one term for each type of
Guideline.

- Are IoT Devices allowed to be non-stub resolvers?  While I agree that they
are most likely to be Sub Resolvers, I don’t see why this would be required. 
Either way the document should explicitly state the guideline, i.e., something
like “IoT Devices SHOULD/MUST be implemented as a Stub Resolver.”

Specific:

- The “MUST” in the second paragraph of section 3.2 seems unaligned with the
use of SHOULD in the rest of the paragraph. Specifically it covers requirements
already covered in RFC5452, so why not just make RFC5452 a MUST and drop the
sentence, or just leave it as a “SHOULD” and drop the now redundant sentence?

- Section 4.2.  I would have expected that the requirement would be for
user/operator configurable TTL values with a default values “that are
appropriate for device operations, …”

I’m omitting my other comments as I think they really just come down to style.