Subject: Re: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03 -- changes since -02

From: Alfred Hönes <[email-masked]>
Date: Fri, 9 Mar 2012 21:33:56 +0100 (MEZ)

Masataka Ohta just wrote:
> Alfred wrote:
>
>> ...
>
> Do you mean you gave up presenting any meaningful use cases?

Masataka-san,

There have been complaints that the draft already shows much too
much context and it should better be stripped down to a pure
specification document ignoring any applicability questions.
I have argued in favor of keeping this "glue" text showing how
IXFR fits into the entire picture.

Are you now saying it should also present some kind of detailed
use case analysis or applicability statement, far beyond what is
said in Section 1 and Appendix A (motivation -- by existing use
cases -- for IXFR-ONLY)?  I fear this would likely disqualify the
document for Standards Track.  Do you want that?

Otherwise, someone else might undertake the effort of writing a
companion applicability statement draft targeting Informational RFC.
Listening to operators so far, I have not heard about perceived
need for such a document, but you are cordially invited to submit
a draft, if you think it is needed and worth the effort.

> Then, we have no reason to waste our time to read the unrevised
> draft.
>
>             Masataka Ohta

Readers are invited to independently evaluate the question whether
the draft is "unrevised" based on the draft diffs readily available
from:
  <http://tools.ietf.org/html/draft-ah-dnsext-rfc1995bis-ixfr-03>

Kind regards,
  Alfred.

_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 11 Mar 2012 22:37:14 +0900

> specification document ignoring any applicability questions.

That's not mine.

The problem I saw was that the draft lacked use case.

> cases -- for IXFR-ONLY)?

I can see no meaningful use cases in Section 1 nor Appendix A.

While your draft seemingly assumes zones should be purposelessly
condensed, RFC1995 already says:

    But, this feature may not be so useful if an IXFR client has access
    to two IXFR servers: A and B, with inconsistent condensation results.

and

    Information about older versions should be purged if the total length
    of an IXFR response would be longer than that of an AXFR response.

that's why I can't see any meaningful use cases

> I fear this would likely disqualify the document for Standards Track.

Not even BCP, because RFC1995 already stated enough as a practical BCP.

> Do you want that?

Want what?

							Masataka Ohta