Hi Warren, Sorry for the delay - I just got back from a vacation, and am catching up with email.
I will respond to your comments in the next day or two. Thanks for your patience! Shumon. On Sat, Jan 18, 2020 at 5:58 PM Warren Kumari <war...@kumari.net> wrote: > Checking in again... > W > > On Sun, Jan 12, 2020 at 9:23 PM Warren Kumari <war...@kumari.net> wrote: > > > > Hi there, > > > > Firstly, thank you for a well written and easy to understand document. > > > > I have some comments which I think should be addressed before I start > > IETF LC, but they are small enough that if you'd much prefer you can > > just address them after during / after LC (if changes are needed), or > > during IESG review. > > Please let me know LOUDLY which you'd prefer. > > > > 1: Section 3: 3. Validating Resolver Behavior > > I think it would be very useful to mention that this document doesn't > > require any changes to the behavior of validating resolvers > > themselves. It might also be worth mentioning somewhere that this is > > also largely true for authoritative servers - this isn't really a > > protocol change, rather an operational / process set of changes. > > > > 2: " Zone owners will want to deploy a DNS service that responds as > > efficiently as possible with validatable answers only, and hence it > > is important that the DNSKEY RRset at each provider is maintained > > with the active ZSKs of all participating providers." > > This is somewhat ambiguous - it sounds like the zone owner may want to > > deploy a service that is only efficient with verifiable answers (and > > might be inefficient with bogus ones :-)) > > > > 3: A question -- "Authenticated Denial Considerations" > > Some CDNs and similar do funny things with e.g CNAMEs, or may do > > something like generate ACME records or similar. What happens if > > provider A creates e.g _acme-challenge.example.com (or www.example.com > > IN 600 CNAME some-long-account-number.cdn.net) and doesn't tell > > provider B? I understand that the owner names *should* be consistent, > > but I think it is worth adding some text here along the lines of "here > > be dragons" or similar... > > > > 4: The document uses one inceanse of RFC2119 language (RECOMMENDED) - > > please either drop this, or add the 2119 / 8174 boilerplate. > > > > Again, I'm willing to start IETF LC, or wait till you've posted a new > > version, but please let me know. > > W > > > > > > -- > > I don't think the execution is relevant when it was obviously a bad > > idea in the first place. > > This is like putting rabid weasels in your pants, and later expressing > > regret at having chosen those particular rabid weasels and that pair > > of pants. > > ---maf > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
