Peter Thomassen <[email protected]> writes:
[changes mentioned below are at:
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-algorithm-update ]
> Thanks for the update. The new text contains "DNSSSEC" in multiple
> instances (one extra "S").
yikes!
Fixed.
> NEW
> Use for DNSSEC Validation: Indicates the recommendation for using
> the algorithm in DNSSEC validators.
> /
> Implement for DNSSEC Validation: Indicates the recommendation for
> implementing the algorithm within DNSSEC validators.
>
> ... or similar.
Changed!
> Section 2.2 ("Adding and Changing Values"):
> The new paragraph ("Only values ...") says something about the "Use
> for DNSSEC Signing" column and the two "Use for DNSSEC Validation"
> columns, ditto for "implement". The allowed values for the two
> "delegation" columns are missing. Is this intentional?
Fixed.
> Section 6 ("Operational Considerations") has the following:
>
> OLD
> Upgrading algorithm at the same time as rolling to the new Key
> Signing Key (KSK) key will lead to DNSSEC validation failures, and
> users MUST upgrade the DS algorithm first before rolling to a new
> KSK.
>
> This sound like one can deploy a DS record for an algorithm that has not
> DNSKEYs or RRSIGs in the child. This would currently be a violation of RFC
> 6840 Section 5.11.
No, it's saying you shouldn't roll keys at the same time as an algorithm
change. It never indicates (IMHO) that you should deploy a DS record
without DNSSEC in place ("upgrade").
> I may well have misunderstood, but if not, I would suggest dropping
> this paragraph, especially as this rule may be changed (authors of
> draft-huque-dnsop-multi-alg-rules haven't given up).
We can't easily base today's text on a maybe :-/
--
Wes Hardaker
USC/ISI
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
