Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover
draft-ietf-dnsext-rollover-requirements-04

Section 2, paragraph 3:

  Remove the text about what dnsext did and didn't do - not typically
  published in RFCs. ("Several mechanisms...set of requirements.")

Minor things I noticed reading this draft:
 
 - I have no clue what "specification-based" is supposed to mean as a qualifier.  As a reader, the doc would mean the same thing to me if that phrase was simply elided.  Yet it seemed emphasized, so I worry that I'm missing something important.

 - section 5.6: "must allow the implementation to support both automated and manual rollover".  I think this means that even when a trust anchor was obtained automatically, it must be possible for the operator to remove it manually without this change being overwritten by the next RRSet received with that key.  Also, is there a requirement for manual revocation (which is like rollover but without replacement) or manual adding of keys?  

thx,
Lisa

  Based on Gen-ART Review by Spencer Dawkins:

  In section 3, the following paragraph took me several reads to parse.
  I think it's saying: "It should be noted that only the DNSKEY RRs and
  DS RRs that are known to be Trust Anchors are the DNSKEY RRs for the
  root zone, so responsibility lies with the operators of security-aware
  resolvers, and not signed zone operators", but if I got this right,
  putting this thought at the beginning of the paragraph would help a lot.
  >
  > It should be noted that DNSKEY RRs and DS RRs are not Trust Anchors
  > when they are created by the signed zone operation nor are they Trust
  > Anchors because the records are published in the signed zone.  A
  > DNSKEY RR or DS RR becomes a Trust Anchor when an operator of a
  > security-aware resolver determines that the public key or hash will
  > be used as a Trust Anchor.  Thus the signed zone operator that
  > created and/or published these RRs may not know if any of the DNSKEY
  > RRs or DS RRs associated with their zone are being used as Trust
  > Anchors by security aware resolvers.  The obvious exceptions are the
  > DNSKEY RR(s) for the root zone that will be used by many security-
  > aware resolvers.  For various reasons, DNSKEY RRs or DS RRs from
  > zones other than root can be used by operators of security-aware
  > resolvers as Trust Anchors.  It follows that responsibility lies with
  > the operator of the security-aware resolver to ensure that the DNSKEY
  > and/or DS RRs they have chosen to use as Trust Anchors are valid at
  > the time they are used by the security-aware resolver as the starting
  > point for building the authentication chain to validate a signed DNS
  > response.

  Also in Section 3:
  >
  > When operators of security-aware resolvers choose one or more Trust
  > Anchors, they must also determine the method(s) they will use to
  > ensure that they are using valid RRs and that they are able to
  > determine when RRs being used as Trust Anchors should be replaced or
  > removed.  Early adopters of DNS signed zones have published
  > information about the processes and methods they will use when their
  > DNSKEY and/or DS RRs change so that operators of security-aware ...
  >
  Is the point "this manual approach will not scale"?  If so, 
  inserting the word "manual" would help me understand...

  In section 5.1:
  >
  > The automated Trust Anchor Rollover solution MUST be capable of
  > scaling to Internet-wide useage.  The probable largest number of
  > instances of security-aware resolvers needing to rollover a Trust
  > Anchor will be for the root zone.  This number could be extremely
  > large (possibly many millions) if a number of applications have ...
  >
  I'm not sure where the "possibly many millions" is coming from.  If 
  this is the number of security-aware resolvers that we expect to be 
  connected to the Internet, wouldn't this be potentially a larger
  number than this?

  The title of Section 5.2 is "No Intellectual Property Encumbrance."
  Sadly, the title should probably be "No Known Intellectual Property 
  Encumbrance". That's all we can say in the IETF...

  Also in Section 5.2:
  >
  > For this purpose, "royalty-free" is defined as follows: world wide,
  > irrevocable, perpetual right to use, without fee, in commerce or
  > otherwise, where "use" includes descriptions of algorithms,
  > distribution and/or use of hardware implementations, distribution
  > and/or use of software systems in source and/or binary form, in all
  > DNS or DNSSEC applications including registry, registrar, domain name
  > service including authority, recursion, caching, forwarding, stub
  > resolver, or similar.
  >
  Please note that IANAL, but I've been seeing pushback from the open 
  source community about additional conditions on "royalty-free" licenses.
  Do you need to say anything about this?  Would royalty-free with
  reciprocity be acceptable?

  In Section 5.8:
  >
  > Resource Records used as Trust Anchors SHOULD be able to be
  > distributed to security-aware resolvers in a timely manner.
  >
  > Security-aware resolvers need to acquire new and remove revoked
  > DNSKEY and/or DS RRs that are being used as Trust Anchors for a zone
  > such that no old RR is used as a Trust Anchor for long after the zone
  > issues new or revokes existing RRs.
  >
  I don't actually know what "for long" means, in this paragraph. 
  Could you bound it in units? "for more than a few
  minutes/hours/days/weeks/..."?