Subject: [dnsext] draft-kerr-ixfr-only-01

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 20 May 2010 11:02:17 +0200

I quickly scanned this document and was surprised to see in Section
2. IXRF Server Side:

    A IXFR server receiving a DNS message requesting IXFR-ONLY will reply
    as described in RFC 1995 [RFC1995] if it is able to produce an IXFR
    for the serial number requested.

Maybe I'm wrong but I always thought that an IXRF request had as
data the current serial from the requester and that the server only
when it is "higher" (according to the serial arithmetic).

I guess should read the draft (and also the original IXFR RFC) more
closely.

	jaap

PS. These remarks make me a reviewer.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 May 2010 21:40:41 +1000

In message <[email-masked]>, Jaap Akkerhuis wr
> when it is "higher" (according to the serial arithmetic).

A IXFR server can return up-to-date, a delta style response or
a axfr style responses.

IXFR-ONLY removes the latter.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 20 May 2010 14:02:23 +0200

Yes, but that is not the point.

The draft says "the serial number requested" but as far as I know
you doesn't send the serial number you want, you sent the serial
you have.

To give a full citation of RFC 1995:

3. Query Format

   The IXFR query packet format is the same as that of a normal DNS
   query, but with the query type being IXFR and the authority section
   containing the SOA record of client's version of the zone.

This is quite different then what the draft states.

	jaap

---

From: Michael Graff <[email-masked]>
Date: Thu, 20 May 2010 09:53:00 -0500

> when it is "higher" (according to the serial arithmetic).

I'm not certain if others have answered this to your satisfaction or
not, so I'll give it a go.

The server may not have a delta chain stored for what the client has and
the current version.  This would normally cause an AXFR-type response.
This draft would cause it to return an error indicating this.

All other IXFR characteristics seem to remain unchanged from my quick read.

- --Michael

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 20 May 2010 17:57:44 +0200

And fail as well. I know what it is supposed to do. However, the
text is plain wrong. It implies that the has the desired serial
number in the query.

And that is incorrect as far as I know.

	jaap

---

From: Michael Graff <[email-masked]>
Date: Thu, 20 May 2010 11:11:39 -0500

> And that is incorrect as far as I know.

Ahh, when I read that text I read it as:  The client requested serial X.
 I have X+N.  If I have a path between X and X+N, then I can respond
with IXFR.

So, the client DOES send what it has, and the server DOES determine "for
the client's serial" can it construct a path from where the client is to
where the zone is now.

It sounds like there are words to change to make this clear.

- --Michael

---

From: Paul Vixie <[email-masked]>
Date: Thu, 20 May 2010 16:39:46 +0000

> Date: Thu, 20 May 2010 11:11:39 -0500
> From: Michael Graff <[email-masked]>
> 

it is.

> I have X+N.  If I have a path between X and X+N, then I can respond

the client is including X in its request, but is NOT "requesting" X.

> the client's serial" can it construct a path from where the client is to

yes.

> It sounds like there are words to change to make this clear.

+1.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 21 May 2010 10:35:14 +1000

In message <[email-masked]>, Jaap Akkerhuis wr
> text is plain wrong. It implies that the has the desired serial

Add a "s" to "number".

servers have the zone with same serial number for that zone.  In this

servers have the zone with same serial numbers for that zone.  In this

---

From: Mark Andrews <[email-masked]>
Date: Fri, 21 May 2010 10:49:40 +1000

> the client is including X in its request, but is NOT "requesting" X.

It's requesting the changes from X.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 27 May 2010 10:40:39 +0200

> This is quite different then what the draft states.

The draft doesn't say whether "the serial number requested" is the 
serial number you want or serial number you have.  It merely states that 
the server is able to produce IXFR response for the serial number 
requested, not saying anything about serial number sent in response.

But maybe it needs rewording, so it is more clear.

O
-- 
  Ondřej Surý
  vedoucí výzkumu/R&D manager
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: [email-masked]
Date: Fri, 28 May 2010 12:08:32 +0000

> But maybe it needs rewording, so it is more clear.

	the serial number you want presuposes that you have
	a clue as to what the canonical master is currently using
	for serial number values.  to borrow a line from the 
	finacial folks, "Past Performance is No Guarantee of Future Results"

	masters can and do change the format of the SOA and slaves
	are supposed to keep up.

--bill

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 28 May 2010 14:38:02 +0200

Bill,

> 	masters can and do change the format of the SOA and slaves

I am not sure if I understand.  How is this related to IXFR-only?  My 
understanding is that we are just merely describing IXFR behaviour. 
Maybe in a little bit obscured wording which may seems that client is 
sending NEW serial number, but in fact we don't say anything about 
serial number, just that IXFR request has to include serial number 
(which is again pure RFC 1995).

Ondrej

---

From: Brian Dickson <[email-masked]>
Date: Fri, 28 May 2010 09:42:44 -0300

On Fri, May 28, 2010 at 9:08 AM, <[email-masked]> wrote:

> On Thu, May 27, 2010 at 10:40:39AM +0200, OndE ej SurC= wrote:
> [snip]

+1

>        masters can and do change the format of the SOA and slaves
This is being a bit pedantic, but...

The SOA *format* never changes. What may change, is the convention on how
to increment/set the serial number of the SOA, in base-N representation.

E.g. base-10, integer values YYYYMMDDnn, or YYYYJJJnnn (JJJ = julian day of
year).

However, this is just a convention. The SOA serial number is a 32-bit
integer value.
It is monotonically increasing, and is permitted to wrap around.
The allowable (and quite reasonably so) maximum increment for wrapping
arithmetic, is 2^31-1.

So, changing from one convention to another, which would result in a
negative increment, usually requires at least one intermediate serial
number, which must successfully be seen by all slaves, before the change to
the new convention is completed.  Choices of 2^32-2, possibly preceded by
2^31-1, are pretty decent values to use.

Brian

---

From: [email-masked]
Date: Fri, 28 May 2010 13:18:27 +0000

On Fri, May 28, 2010 at 02:38:02PM +0200, OndEej SurC= wrote:
> >>>     >       as described in RFC 1995 [RFC1995] if it is able to produce 
> >>>     an
> >>>     IXFR

	please clarify the phrase;  "Serial Number Requested".

	imho, the slave has a serial number in hand and asks the
	master to send the current serial number.  which is 
	a perfectly fine way to interpret the phrase.  

	it could be helpful to have the slave, when asking the master
	for the current serial number, to pass the slaves serial number
	up to the master, but I can't quite see how the master will use
	the information.

	this thread suggested that one possible interpretation would be to 
	request a specific serial number; e.g.  I would like serial# 64223
	.. which i believe is an incorrect interpretation.

	now if the premise of IXFR-only is to just send the diffs between
	(serial at slave) and (serial at master), then there is the presumption
	that the master has: 

	a) kept track of the state of the zone contents between serial number
	   increments
	and
	b) the master has not changed the format of the SOA

	for example, if the slave as IXFR-only signals to the master: "here
	is my current serial number,  2010052800, please send me all updates
	since then" and the master responds with: "the current serial number
	is 9"  --  what should happen?   the master changed the format of the
	serial number it was using in "mid-stride".

--bill
> 
> Ondrej
> -- 
>  OndEej SurC=
>  vedoucC- vC=zkumu/R&D manager
>  CZ.NIC, z.s.p.o.    --    LaboratoEe CZ.NIC

---

From: [email-masked]
Date: Fri, 28 May 2010 13:27:23 +0000

> 2^31-1, are pretty decent values to use.

	right.  that was sort of the point.  the master can reset the value
	at any point in time and the slaves have to react to that change.
	at which point an IXFR-only slave has to pull the whole zone.

	AXFR covers most use cases (or should)
	IXFR is a local optimization
	IXFR-only is even more specialized... 

	I am not persauded of the relative value of IXFR-only.  but then
	again, I'm not one for putting (near) real-time constraints on the
	DNS

--bill

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 28 May 2010 15:49:36 +0200

> 	serial number it was using in "mid-stride".

IXFR-only doesn't change (or want to change) any behaviour of IXFR 
except fallback to AXFR.  Interpretation where slave request specific 
version number is wrong.  Slave in IXFR-only behaves exactly same as in 
IXFR (except of different QTYPE).

Ondrej

---

From: [email-masked]
Date: Fri, 28 May 2010 14:02:43 +0000

> IXFR (except of different QTYPE).

	the reason for fallback to AXFR are/were elaborated in previous
	rfc and wg discussion. what I think you are suggesting is that 
	ixfr-only nodes need to recreate without fallback, the same
	functionality as axfr in those circumstances when a full zone
	transfer is needed.

	havingtwo distinct functions that perform the same act sort
	of requires a clearly stated value proposition and I don't 
	see that in IXFR-only.

--bill

---

From: Brian Dickson <[email-masked]>
Date: Fri, 28 May 2010 11:27:53 -0300

>        b) the master has not changed the format of the SOA
Actually, no. (B) does not factor in at all, only (A).

>        serial number it was using in "mid-stride".
Either nothing (because the SN is lower and the delta modulo 2**32 exceeds
2**31), or whatever the normal IXFR response would be, for suitable values
of "2010052800" and "9". :-)

The absence of an intermediate "BigNumber" SOA SN between the SN occurrences
of 2010052800 and 9, is an operator error.

The slave *should* have had a chance to request an IXFR 2010052800 ->
3000000000 (or so), which could have been an "empty" IXFR consisting of only
the new SOA records (2 in a row with no other data). And then its next IXFR
request would have been a wrap-around event of 3000000000 -> 9, which would
be no different than if it had been an IXFR from 2010052800 -> 2010052801.

It's best not to conflate/confuse the issue. SN format has nothing at all to
do with IXFR vs AXFR.

Brian

---

From: Joe Abley <[email-masked]>
Date: Fri, 28 May 2010 16:38:08 +0200

> 	at which point an IXFR-only slave has to pull the whole zone.

An IXFR-only slave has options -- it can implement something different from AXFR to transfer the whole zone, it can shut itself down and remove itself from an anycast cloud, it can try other servers with IXFR-only and then (once convinced that no masters can provide an IXFR) it can request an AXFR.

An IXFR slave does not have those options.

> 	AXFR covers most use cases (or should)

It doesn't cover the case when you definitively don't want to transfer the whole zone.

> 	IXFR is a local optimization

IXFR is not local, in the sense that it needs to be implemented in both client and server. (I can't think of another contextual meaning for "local" in your comment.)

> 	IXFR-only is even more specialized... 

I don't understand the basis for the comparison. IXFR-only is identical to IXFR except that it doesn't fall back to AXFR.

> 	I am not persauded of the relative value of IXFR-only.

But presumably given the traffic on this list you are able to confirm that it has non-zero value for others.

Joe

---

From: Joe Abley <[email-masked]>
Date: Fri, 28 May 2010 16:38:54 +0200

> 	of requires a clearly stated value proposition and I don't 

Do you mean you don't see any value to the concept, or that you find the text in the draft lacking?

Joe

---

From: [email-masked]
Date: Fri, 28 May 2010 14:36:43 +0000

> of 2010052800 and 9, is an operator error.

	which operator error?  the master operator or the slave operator?

> be no different than if it had been an IXFR from 2010052800 -> 2010052801.

	note the operative "should" ... this is a statement made from the 
	perspective of the slave.

> It's best not to conflate/confuse the issue. SN format has nothing at all to

	except in the case of determining fall-back - when there is no
	difference between an AXFR and an IXFR wrt the number of records 
	sent.
	
	I don't think that IXFR-only should recreate a new fallback method
	independent of AXFR.  ergo, I don't see the value in IXFR-only.

--bill

---

From: Joe Abley <[email-masked]>
Date: Fri, 28 May 2010 16:56:21 +0200

On 2010-05-28, at 16:49, [email-masked] wrote:

> On Fri, May 28, 2010 at 04:38:08PM +0200, Joe Abley wrote:
>> 
> 	anycast cloud?  is a recent implementation artifact driving protocol?

Is it so unusual for recent implementation artifacts to cause demand for new features?

> 	if there is axfr fallback, then how does it qualify for IXFR-only designation?

So you're complaining about the name? :-)

> 	sure - and there is enough traffic on other lists to confirm that djbdns has a non-zero
> 	value to others.  djbdns and ixfr-only fit small, niche markets.  does that mean one
> 	should put effort into pushing a standard through for either of them?

The reason to standardise a protocol is to facilitate interop.

What reason do you imagine there might be to standardise an implementation of a protocol? What does that even mean?

Joe

---

From: [email-masked]
Date: Fri, 28 May 2010 14:49:46 +0000

> It doesn't cover the case when you definitively don't want to transfer the whole zone.

	right - hence -most- use cases.  

> IXFR is not local, in the sense that it needs to be implemented in both client and server. (I can't think of another contextual meaning for "local" in your comment.)

	local to a specific delegation, not a generic protocol syncronization method

> I don't understand the basis for the comparison. IXFR-only is identical to IXFR except that it doesn't fall back to AXFR.

	er... except it can, per your statement above.

--bill

---

From: [email-masked]
Date: Fri, 28 May 2010 14:54:09 +0000

> Do you mean you don't see any value to the concept, or that you find the text in the draft lacking?

	the value in the concept is suspect and the text supporting it tries to 
	replicate existing functionality w/o clear benefit.

--bill

---

From: [email-masked]
Date: Fri, 28 May 2010 15:01:50 +0000

> Is it so unusual for recent implementation artifacts to cause demand for new features?

	yeah - it is.

> So you're complaining about the name? :-)

	and the implied functionality behind the name

> The reason to standardise a protocol is to facilitate interop.

	and yet NAT was never standardized. 

> What reason do you imagine there might be to standardise an implementation of a protocol? What does that even mean?

	this is not the list for metaphysical discussion.  But thanks for asking.
	perhaps over a beer.

---

From: Joe Abley <[email-masked]>
Date: Fri, 28 May 2010 17:08:46 +0200

>> Is it so unusual for recent implementation artifacts to cause demand for new features?

Weird, because I find it hard to think of a new protocol that isn't driven by an implementation artifact.

> 	and the implied functionality behind the name

I think at this point your lack of enthusiasm for using this feature, if standardised and implemented, is clear.

> 	and yet NAT was never standardized. 

And interop consequently suffered.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 28 May 2010 11:25:28 -0400

Moderator hat.

Bill,

> 	this is not the list for metaphysical discussion.  But thanks for asking.

I think we're well down the rathole in the above.  

If you have an objection to the protocol or it being a WG work item
(which, given the number of reviewers who've already volunteered, it
will otherwise clearly become), you need to make it.  So far, the only
real objection I've seen from you seems to be that you don't think the
functionality is needed.  Since others have outlined their use-case,
however, I don't think that objection has much merit.  Is there
something harmful that you see in this protocol proposal?  If so, what
is it?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 29 May 2010 02:00:34 +1000

> 	up to the master, but I can't quite see how the master will use

Which is exactly what it does.  The master looks in its change history and
generates a response which will bring the client up to date.
 
> 	b) the master has not changed the format of the SOA
 
A SOA serial is a 32 bit number.  

> 	serial number it was using in "mid-stride".

It indicates that the slave is ahead of that master and it should try another
one.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 29 May 2010 02:20:23 +1000

> 	replicate existing functionality w/o clear benefit.

The problem arises from the use of collapsed deltas rather than sending all
the individual deltas to the intermediate master.   The intermediate masters
then don't always have the desired starting point the slave desires when it
switches between intermediate masters.

The are two possible fixes.
1. Stop sending collapsed deltas to the intermediate masters.  One of the
   reasons named doesn't generate compressed deltas is to avoid this problem.
2. Don't let the slave switch masters.
2. Implement IXFR-only.

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 30 May 2010 07:19:10 +0900

> So far, the only
> however, I don't think that objection has much merit.

That's creeping featurism with no engineering legitimacy.

						Masataka Ohta

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 30 May 2010 11:57:49 -0400

Nonsense. It is not creeping featurism to add a feature not currently  
available in order to support a use case not currently supported. It's  
just adding a feature. Otherwise, we should never add anything to an  
existing system.

A
-- 
Andrew Sullivan
<[email-masked]>

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 31 May 2010 16:08:37 +0900

Andrew Sullivan wrote:

> just adding a feature.

You seems to have a very strange definition of creeping featurism.

Can you or someone else show me an example of creeping featurism
where an added feature has no use case?

For usual definition on creeping featurism, see, for example:

	http://catb.org/jargon/html/C/creeping-featurism.html

						Masataka Ohta

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 31 May 2010 23:37:51 -0400

> where an added feature has no use case?

Of course not.  But adding a feature is not automatically creeping
featurism.  I (perhaps foolishly) read your remark about creeping
featurism to be part of an argument in which you reasoned that, since
this was creeping featurism, it was bad.  So I contested your claim
that it was obviously creeping featurism (for which you would need
some argument like that it was unplanned, that it was worse than
alternatives, or that nobody really needs such a feature).  But I now
perceive that you were more likely engaged in _ad hominem_, calling
the feature names ("creeping featurism") instead of actually arguing
why it is a bad idea.  Either that, or your argument begs the
question, since it assumes the feature is not needed in order to call
it creeping featurism.

In any case, the objection is still weak.  I'd need something stronger
than that to revise my view that the WG can reasonably adopt the draft
as a WG document.  (See the recently posted draft charter.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.