Subject: Re: [dnsext] axfr-clarify-10 section 7, Zone Expiry Timer

From: Alfred Hönes <[email-masked]>
Date: Thu, 29 Jan 2009 20:19:25 +0100 (MEZ)

Hi Edward,

I thought enough folks had insisted in moving the zone management
stuff and zone expiry discussion into the AXFR draft, and did not
oppose in my recent re-review.

As it now becomes clear, that has not been the case.

In RFC 1034 and RFC 1035, zone management, including the strategy
of when to perform zone updates (now: AXFR or IXFR), is part of
the description of the SOA RR, which contains the per-zone
parameters for the strategy.

Section 1.4 of the AXFR draft already mentions the relevant
part of RFC 1034: section 4.3.5; the complementary information
for SOA can be found in section 3.3.13 of RFC 1035.

Clearly, the strategy to invoke AXFR is at a higher layer than
-- you may say a meta-layer above -- the AXFR protocol itself.

The AXFR draft's topic is the AXFR protocol proper, not the
higher layer protocol that might invoke it.

Therefore, I strongly suggest to declare details of that
'application protocol' out-of-scope of the AXFR draft.
A concise narrative description might be appreciated by readers
to help set the context, but the normative details (to whichever
degree they might need to be specified in an RFC) should not be
part of the draft.

Currently, the WG has not yet decided whether the expiry problem
is worth detailed additional specification or should be left to
the creative imagination of implementers and administrators.
Trying to pack this controversial topic into the AXFR draft
would certainly further hold off the progress of the AXFR draft.
This should be avoided.

There's at least one more reason for not interfering with the
RFC 1034/1035 elaborations on SOA parameters:  As we all know,
the SOA 'MINIMUM' has later been redefined to be the negative
caching TTL.  Further, there is widespread bad use (I politely
avoid the term 'abuse') of the MNAME and RNAME SOA parameters.
Therefore, I see the medium-term need for a coherent updated
specification of the SOA RR anyway; this could also be a BCP
document anchored in DNSOP.  I would very much prefer all SOA
parameter related discussion to be contained in as few documents
as possible, and such single future new document would be the
proper place for it.

Kind regards,
  Alfred.

-- 

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