DNSSEC editors Question list

["Olaf M. Kolkman" <olaf@ripe.net>]

Update on the state of the DNSSECbis questions/issues list.

All questions that where numbered are resolved. There are some open
ended discussions on the list once these are resolved the document
editors will roll the versions. We will probably do last call on those
versions.

Details of the questions and resolutions see below and
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02183.html


Please send textual nits on the dnssec bis document set to the dnssec
editors (dnssec-editors@east.isi.edu) and 'content' to this list.


On a related note the records document and 'NSEC++' are
intertwined. Please review 'NSEC++' too. The text in that document
is intended to be cut-n-pasted into dnssecbis.


-- Olaf
   DNSEXT co-chair

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC



This is the list of open questions I posted recently.

The following questions are now marked as resolved:



> Q18: RRsig TTL violating 2181
>
>      Default action, based on sense of the room at IETF58, is to permit
>      the TTL of SIG RRs with same ownername and CLASS to be different and
>      to have the TTL of the SIG RRs bound to the TTL of the TYPE of the
>      RR they sign.

      Resolved: No comments on the list, default action taken as consensus.


> Q19: Suppression of duplications
>
>      This issue is about the canonicalization process by the signer and
>      the verifier.
>
>      Duplicates are specifically forbidden. On the list there have been
>      several opinions with regards to how to deal with this issue.
>
>      We propose the following text as consensus position:
>
>      Duplicate RR records are not allowed exist according to
>      [RFC2181]. Implementations MUST therefore treat duplicate RR
>      records as protocol errors. Signers and verifiers MUST
>      canonicalize duplicate RR sets by removing duplicate RRs from
>      the set if the implementation is designed to be liberal in
>      handling protocol errors.

      Resolved: No comments on the list, default action taken as consensus.


>  Q20: Expansion of wild cards in the authority section.
>
>      Default action, based on sense of the room at IETF58, is to not
>      expand the owner names of e.g. wildcard  NSEC RRs.
>     
>      There was a little discussion on the list; a question that turned 
>      into support.

      Resolved: Default action taken as consensus.


>  Q21: Caching and reuse of NSEC RRs
>
>      Default action, based on sense of the room at IETF58, is to
>      change the text not to strongly prohibit any reuse of cached
>      NSEC RRs, but to allow, and not encourage, (MAY language) reuse
>      to synthesize negative answers for which QNAME, QLASS has an
>      NSEC RR of same ONAME and CLASS in cache that proves the non
>      existance of QTYPE.
>


Resolved:
      There is consensus on making this requirement less restrictive
      in the sense mentioned above.

      Note that there was an issue raised related to this question
      recently.
      (http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02257.html)
      That question essentially asks to make the language with respect
      to cache behaviour even less restrictive. We'll treat this issue
      independently.




> Q22: What should the failure mode be if compressed names are
>      encountered in RRs other than the "well-known" RRs; Should the
>      verifier be liberal or fail. (Remember compression is only
>      allowd for "well known RRs, RFC3597 section 4 and RFC1123)
>
>      The sense of the room at IETF58 that senders should not send RRs
>      with compressed data and receivers should "not throw a fit".
>
>      Since, in contrast to Q19, the canonicalization for the signer
>      and the verifier are specified (records section 6.2) so the
>      question is if the "robustness principle" should be specified at
>      all.
>
>      If you think that there should be language to specify how to
>      apply the robustness principle for when RRs other than the "well
>      known" RRs are compressed than please supply text to go into one
>      of the DNSSECbis draft.
>
>      Default action will be not to add recomendations about compression
>      and decompression before sending or after receiving. 


Resolved, no text was suppied, recomendations on compression and
decompression will be added and taken as consensus of the group.



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