Last Call Review of draft-ietf-add-ddr-07
review-ietf-add-ddr-07-artart-lc-fossati-2022-06-28-00
Request | Review of | draft-ietf-add-ddr |
---|---|---|
Requested revision | No specific revision (document currently at 10) | |
Type | Last Call Review | |
Team | ART Area Review Team (artart) | |
Deadline | 2022-07-08 | |
Requested | 2022-06-24 | |
Authors | Tommy Pauly , Eric Kinnear , Christopher A. Wood , Patrick McManus , Tommy Jensen | |
I-D last updated | 2022-06-28 | |
Completed reviews |
Intdir Last Call review of -08
by Juan-Carlos Zúñiga
(diff)
Artart Last Call review of -07 by Thomas Fossati (diff) Genart Last Call review of -08 by Robert Sparks (diff) Secdir Last Call review of -08 by Benjamin M. Schwartz (diff) |
|
Assignment | Reviewer | Thomas Fossati |
State | Completed | |
Request | Last Call review on draft-ietf-add-ddr by ART Area Review Team Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/art/PT-6Rhoa4WieVi3lmSFMhlvbSo4 | |
Reviewed revision | 07 (document currently at 10) | |
Result | Almost ready | |
Completed | 2022-06-28 |
review-ietf-add-ddr-07-artart-lc-fossati-2022-06-28-00
This looks like a very useful document. It's short but packed with information. It's largely very well written, though I found Section 4.1 slightly harder to parse than the rest and I think that area needs some (small) editorial tweaks before the document can be shipped. # Minor issues Why the following isn't a MUST NOT? Clients SHOULD NOT automatically use a Designated Resolver without some sort of validation, such as the two methods defined in this document or a future mechanism. -- This bit is puzzling: A client MUST NOT use a Designated Resolver designated by one Unencrypted Resolver in place of another Unencrypted Resolver. There seems to be some context missing to explain why a client should found itself in that position. What I seem to understand from the text that follows: As these are known only by IP address, this means each unique IP address used for unencrypted DNS requires its own designation discovery. This ensures queries are being sent to a party designated by the resolver originally being used. is that clients must go through the designation process when their network attachment changes / they are re-configured WRT their UR. And that's because there is strict administrative coupling between a UR and its DRs that would be subverted otherwise. I am scanning this for the first time and I may be off on a tangent space, but if my reading is correct, then the text could be reorganised a bit to make the context for the requirement clearer. -- I found this other bit hard to parse: Generally, clients also SHOULD NOT reuse the Designated Resolver discovered from an Unencrypted Resolver over one network connection in place of the same Unencrypted Resolver on another network connection. What about: If a client is configured with the same Unencrypted Resolver's IP address on two different networks n1 and n2, a Designated Resolver that has been discovered on n1 SHOULD NOT be reused on n2 without repeating the discovery process. instead? -- In the IANA section IANA is requested to add an entry in "Transport-Independent Locally-Served DNS Zones" registry for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain", listing this document as the reference. Ignorant question: is there an associated delegation of 'resolver.arpa.' needed in the '.arpa.' zone? Or is that not necessary? # Nits I've submitted a PR with a few typos fixed. cheers, thanks!