Re: [dnsext] draft-ietf-dnsext-rfc1995bis-ixfr -- questions on s3.2.3

Regarding the final point in my previous posting ...

>> ...
>>
>> Finally, a closely related topic / question:
>>
>> (5)
>> The example of "fallback to AXFR" in the draft (at the very end of
>> Section 2) currently suggests that, for efficiency at both the IXFR
>> server and the IXFR client, for full zone transfer (fallback to AXFR)
>> an IXFR server (typically) sends the zone RRs grouped by RRset.
>>
>> It has been correctly observed that this ordering does not correspond
>> to a requirement contained in the new AXFR specification, RFC 5936.
>>
>> Should this behavior be recommended/RECOMMENDED in the draft
>> for new IXFR server implementations?

Based on the feedback received, some implementations do this grouping
by RRset, but it looks like implementers would prefer the identical
set of RR placement/ordering requirements as in RFC 5936 for AXFR,
and not to have recommendations beyond that in the IXFR document.
I.e., there will be no ordering requirements for the RRs of a zone
beyond the dual (and dual-purpose) placement of SOA RRs (conveying
the SOA RR as such and serving as structure tags or 'sentinels'
for the response).

So the final part of Section 2 in the next version of the rfc1995bis
I-D will avoid mention of RRsets. My working copy of the draft now
says, including the new explanation at the end:

!  In contrast, in the case of fallback to AXFR, the IXFR response would
!  convey, in order:
!
!     *  SOA for sn_n    # first instance
!     *  {other RRs of the zone at sn_n, in arbitrary order}
!     *  SOA for sn_n    # repeated as trailing delimiter
!
!  In these examples, for convenience "other RRs ..." is used as a
!  shorthand for the more precise words "zero or more other RRs ...".

Agreed?

Kind regards,
  Alfred.

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext