Hi everyone RFC6891 says this:
> Any OPTION-CODE values not understood by a responder or requestor
> MUST be ignored. Specifications of such options might wish to
> include some kind of signaled acknowledgement. For example, an
> option specification might say that if a responder sees and supports
> option XYZ, it MUST include option XYZ in its response.
There is no generic way for a client to know that an option was not
handled at the server side. This is sometimes a problem when introducing
new options - while option specifications typically implement some sort
of reply signalling, it's not always the case where the client can know
with a missing option if it was not included because of lack of support,
or due to some other cause.
Is it worth introducing a reply EDNS option whose OPTION-DATA contains a
list of all the 16-bit OPTION-CODEs that were ignored from the query
message, and make it a MUST requirement?
Mukund
pgpJv2CEg9JC6.pgp
Description: PGP signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
