Subject: ISSUE 6: draft-moreau-dnsext-tak-req-00 has other useful requirements, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-01

From: Suresh Krishnaswamy <[email-masked]>
Date: Mon, 12 Jun 2006 13:22:01 -0400 (EDT)

ISSUE 6:  draft-moreau-dnsext-tak-req-00 has other useful requirements, 
RE-OPENED

Based on clarification from Olaf and Thierry I intend to use replacement 
text from
<http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00693.html> 
for the definition of the "Non-degrading trust".

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Mon, 12 Jun 2006 13:22:25 -0400 (EDT)

Issue 9: Relevance to working group charter, NEW

In 
<http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00630.html> 
Thierry raised a couple of objections to the wording in section 5.2. Wes 
provided replacement text in
<http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00631.html> 
to address the first. Olaf noted in 
<http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00696.html> 
that the second objection was probably a non-issue.

The replacement text from Wes will be merged into the document and with 
that the issue will be considered CLOSED.

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Mon, 12 Jun 2006 13:22:14 -0400 (EDT)

ISSUE 8: Wording of existing requirements, RE-OPENED

In <http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00624.html> I 
included two new requirements based on my interpretation of various 
comments on the list.
     * 5.5 Detection of Stale Trust Anchors
     * 5.11 Support for Trust Anchor Maintenance Operations

Of these, I read Ed's mail in 
<http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00649.html> 
as support for requirement 5.11 and lack of support for 5.5. The intent of 
5.5 is really to say that the solution must allow the security-aware 
validating resolver to identify when it is "out-of-sync" so that
initial trust may be re-established. Olaf has offered the following text 
as replacement:

    The Trust Anchor Rollover solution MUST allow a validating security-
    aware resolver to be able to detect if the DNSKEY or DS RR(s) can no
    longer be updated given the current set of actual trust-anchors so that
    initial trust may be re-established.

I also propose dropping the sentence "The same solution SHALL be able to 
be used to maintain Trust Anchors for the root zone and other zones." from 
5.3 (again from Ed's mail above).

I wasn't exactly sure what the proposed actions for 5.1, 5.4 and 5.12 were 
so I've not made any changes.

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Mon, 12 Jun 2006 13:22:49 -0400 (EDT)

ISSUE 10: Use of RFC 2119 terminology, NEW

This document is to be used as guidance for selecting a rollover solution. 
It may well be that not all the requirements can be met in which case 
trade-offs will be made. The use of 2119 terminology may be confusing 
here and Olaf has proposed the following change:

REMOVE:
   The use of the RFC-2119 words in this version of document is
    preliminary in nature and feedback is requested as to the correct
    word to use for each of the requirements.

ADD:
   The use of RFC-2119 words in the requirements is intended to
   unambiguously describe a requirement. If a tradeoff is to be made
   between conflicting requirements when choosing for a solution the
   requirement with MUST language will have higher preference than
   requirements with SHOULD, MAY, or RECOMMEND language. It is understood
   that a tradeoff may need to be made between requirements that both
   contain MUST language.