Subject: edns0 again

From: Robert Elz <[email-masked]>
Date: Wed, 30 Jun 1999 09:57:46 +1000

Last Saturday I indicated that a new edns0 was available, and that
if no objections were received it would be passed along to the IESG
to reconsider.

I also said ...

   But because there are a couple of other minor changes in the draft - it
   now explicitly says that only one OPT RR is permitted in a query, and also
   gives some advice about chosing values for the payload size, and when that
   might be done, I will wait for a couple of days before doing that.

There has been some concen that the "and also gives some advice about chosing
values for the payload size, and when that might be done" may have been
too cryptic, and that I ought to have made sure that everyone gets a chance
to actually see the new text.    That is, more than by simply expecting
everyone to spot it in the draft...

Point taken, this is the new part ...

   4.5.3. The requestor's maximum payload size can change over time, and
   should therefore not be cached for use beyond the transaction in which
   it is advertised.

   4.5.4. The responder's maximum payload size can change over time, but
   can be reasonably expected to remain constant between two sequential
   transactions; for example, a meaningless QUERY to discover a responder's
   maximum UDP payload size, followed immediately by an UPDATE which takes
   advantage of this size.  (This is considered preferrable to the outright
   use of TCP for oversized requests, if there is any reason to suspect
   that the responder implements EDNS, and if a request will not fit in the
   default 512 payload size limit.)

   4.5.5. Due to transaction overhead, it is unwise to advertise an
   architectural limit as a maximum UDP payload size.  Just because your
   stack can reassemble 64KB datagrams, don't assume that you want to spend
   more than about 4KB of state memory per ongoing transaction.

If anyone sees any serious problems with that, you have about 24 hours (a
little more actually) to make your point on the list, or we will consider it
acceptable.

If you would like to suggest different wording (or clearer wording) then
that can also be done - if there are any alternatives offered that seem
acceptable to people, the IESG may see fit to accept the draft, provided
that it is updated in some specific way that has been suggested to them.

Or, if there are just style issues, we could just hold that and fix it
when the doc is ready to advance to DS status in 7 or 8 months or so.

Personally (with no chair hat on any more) I see no problems of substance
with those paragraphs.   The first tells servers that they don't need to
remember the size option for every resolver they have ever talked to, and
in fact should not (not that I can imagine any server would have wanted to)
and more importantly, indicates to resolvers that the size option needs to
be set in every query where it is needed.

The second para is more complex, and deals with resolvers sending update
packets, where the initial packet is the one that will be the big one.
If no memory was ever permitted, big updates would be a problem.  Typically
(I believe) resolvers will perfomr a query before attempting an update
(eg: to discover if the data needs changing) - it seems reasonable to allow
the resolver to discover the server's max packet size from the answer to
that query, and then use that in the subsequent update packet, if one is
needed.

The third is just some words of guidance, and while I don't much like the
chatty nature of it, I don't see it as something to hold up the draft now
either.

Any comments?

kre