Again, a little trouble understanding the points.

At 8:44 +1100 1/23/08, Mark Andrews wrote:
>Note 2.1.1.b The value in this field has no meaning in the
>context of AXFR. For the client, RECOMMENDED that the value be zero.
>For the server, RECOMMENDED ignoring this value.
>
> I know we are talking about the query in section 2 but it
> needs reinforcement as AA has meaning in the response.
>
>Note 2.1.1.b The value in this field has no meaning in the context
>of a AXFR QUERY. For the client, RECOMMENDED that the value be
>zero. For the server, RECOMMENDED ignoring this value.


I suppose you are suggesting to replace the first 2.1.1.b with the
first. I don't see a second 2.1.1.b in my doc (I am prone to such
numbering errors).

> I suspect this is a matter of a oversite by IANA.


What is "this" referring to?

>Note 2.1.1.c The Z bit is no longer registered with IANA (no document
>cited for change). RECOMMENDED client set to 0, server MUST ignore.
>
> To the best of my knowlegde it is still zero on send. There
> is debate over ignore / return FORMERR on receive.


When it comes to protocol design, my guidance on this is, if the bit
being 1 is not expected but otherwise is not confusing, ignore it.
There's little sense in trying expand the number of error states.

Future-proofing benefits too, ignoring the MUST be set to zero's
allows a future implemention to try to make use of the extensions
without wasting probe messages.

The issue about whether it MUST be 0 or is something else is
comlicated by the fact that it has changed in the registry ([IANA])
and we don't know why.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar

Think glocally. Act confused.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: