Subject: Re: [dnsext] draft-ietf-dnsext-rfc2672bis-dname WGLC

From: Alfred Hönes <[email-masked]>
Date: Fri, 5 Sep 2008 00:53:01 +0200 (MESZ)

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

---  WGLC comments on draft-ietf-dnsext-rfc2672bis-dname-14  ---

Preliminary note:
  I apologize for having been out of sync with the WGLCs in progress
  and appreciate the reminder by the chairs, and the WGLC extensions
  they have announced today in
<http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01688.html>.

draft-ietf-dnsext-rfc2672bis-dname is an important part of the
effort to update and clarify the core DNS specification and
its most important extensions.
The original specification of the DNAME resource record in
RFC 2672 has been challenged and discredited as being too
fragile and onerous for production DNS deployment.

In the meantime, experience has been gained with DNAME,
and it has turned into an important component in building
better manageable and more scalable configurations for some
important parts of the distributed DNS database, in particular
the reverse IPv6 tree and for ENUM support.

Building on this experience and extensive discussion on the WG
list, this draft successfully undertakes the task to consolidate
the original specification to a more precise and detailed document,
as required by current expectations for an IETF Standards Track
RFC.  Beyond replacing RFC 2672, this draft consistently also
updates the two RFCs that have argued against DNAME.

I already had reviewed three previous versions of the draft and
found all issues raised being addressed satisfactorily in the
succeeding iterations of the draft.

Once more studying the -14 version this week, I found no new
issues to discuss.

The open request to modify the first paragraph of Section 3.4, cf.
<http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01150.html>,
aims at a more predictable behavior of caching recursive name servers
than currently specified in the draft, under very specific boundary
conditions, the (hopefully transient) presence of conflicting data
(potential occlusion of other RRsets by a DNAME RR).
Like another voice on the list, I also support this change request,
but with a slight correction in the last line of the change proposal:

   s/subject the rules/subject to the rules/
                              ^^^^

Besides this detail, I also strongly support proceeding with
this draft and submitting it to the IESG for publication as
a Standards Track RFC.

It might be wise to perform another update cycle to incorporate the
above change, but I also would have no objections to deferring that
until after IETF LC.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

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