Re: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec

[Warren Kumari <[e-mail]>]

On Sat, Jan 18, 2020 at 8:43 PM Shumon Huque <[e-mail]> wrote:
>
> 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!

No worries, I just wanted to make sure y'all had seen this, and that I
hadn't missed something / wasn't causing delay.

W


>
> Shumon.
>
> On Sat, Jan 18, 2020 at 5:58 PM Warren Kumari <[e-mail]> wrote:
>>
>> Checking in again...
>> W
>>
>> On Sun, Jan 12, 2020 at 9:23 PM Warren Kumari <[e-mail]> 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



-- 
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