WGLC: white lies documents

[Olaf Kolkman <olaf@ripe.net>]

Dear Colleagues,


This message starts the working group last call for

       draft-ietf-dnsext-dnssec-online-signing-00
and    draft-ietf-dnsext-dns-name-p-s-00

The first draft describes the mechanism of what has been called white
lies. The second draft describes one specific function that can be
used to implement the scheme.


The editors off draft-ietf-dnsext-dnssec-online-signing-00 have
reported that except for a few minor editorial changes the document is
technically solid.  After rereading the document we think it is ready
for last call.

There are two particular issues that we want working group guidance
on. They are of a somewhat bureaucratic nature.

1st issue.  The document indicates it updates 4034 and 4035. Sam
Weiler has paraphrased the changes as:

- RFC4034 Section 4.1.1 describes how the NSEC "next domain name" field
  contains the next owner name in the canonical ordering of the zone.
  Again, Epsilon does something different.

- RFC4035, Section 2.3, 3rd paragraph requires (with a 2119 MUST NOT)
  that an NSEC RR not be the only RR at a given owner name.  When
  Epsilon NSEC RRs are synthesised to cover a non-existing name, that
  constraint is violated.  This should not require any changes to
  deployed code, but it is a change in 2119 language.

It has been argued that it is impossible to determine with certainty
that the NSEC is generated by an "epsilon generating server" or by a a
server that is serving NSECs generated off-line.

The question to the working group is: Should this specification update
4034 and 4035?  That question is related to the second issue.



2nd issue.

Should this document be targeted as experimental or follow the
standards track. We had some discussion with one of the editors.
There are arguments for this document to be published as experimental.

   + We are not aware of anybody who is willing to use this technology
     in production. Some of the people that showed interest earlier
     have been telling us that an on-line key is prohibitive to
     deployment.

   + There has only been one reported proof-of-concept implementation.

   + We are not aware of any implementation that plans to include this
     technology.

On the other hand the technology is not seen as dangerous and there is
"neither implementation nor operational experience is required for the
designation of a specification as a Proposed Standard." [2026 Section
4.1.1].

Our interpretation of RFC2026 section 6.3 is that if this document
updates 4034 and 4035 it will need to go on the standards track.

The chairs favor the document to be published as experimental, with
removal of the "update notice" and a small addition to the
introduction of the document along the lines off.

  This document is based on a relaxed interpretation of requirements
  in RFC 4034 and 4035 that does not noticeable on the wire and does
  not lead to changes in deployed DNS clients. If the technique
  described herein would be published on the "standards track" the 
  document would update 4034 and 4035.

The chairs also think the second draft "dns-name-p-s" is to appear as
experimental.

Hereby we issue a working group last call that will terminate
September 1, 2005. This is longer than normal since it is vacation
time.


Your chairs,

Olaf and Olafur

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