At Tue, 24 Nov 2015 01:28:26 +0530, Mukund Sivaraman <m...@isc.org> wrote:
> > I'm not sure if I understand the concern...do you mean, for example, > > if an AXFR consists of the following 3 messages: > > > > Message1: beginning SOA and some RRs > > Message2: some intermediate RRs > > Message3: some more intermediate RRs > > Message4: some more RRs and ending SOA > > > > the client side of AXFR receives them in the order of, e.g., Message2, > > Message3, Message4, and then Message1? That is, Message1 is not > > necessarily sent/received first and/or Message4 is not necessarily > > sent/received last? > > Yes. Without them being in order, it doesn't seem the client can > determine upon timeout if all messages corresponding to the transfer > have been received, or if the transfer is incomplete. > > Example: > > (1) Message1, Message4, Message2, Message3 received. > Timeout complete and TCP still connected. > > (2) Message1, Message4, Message2 received. [Message3] not received when > timeout complete and TCP still connected. > > How can client know that in (2), the whole transfer was not received? In both cases the client should simply consider it the end of AXFR when it sees Message4 (and the client would treat it as an error when it sees subsequent Message2 or Message3). To me, that's a quite obvious consequence of the fact that an AXFR must begin and end with an SOA and there's no required ordering in the intermediate RRs. If there's indeed an implementation that doesn't interpret *the obvious* that way, it might be worth noting explicitly, but from what I heard and if I understood it correctly, that rather seems to be a pure implementation problem than a protocol documentation issue. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
