[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
EDNS0 revisions
i propose to revise RFC 2671 as follows:
1. remove extended label type. (this "didn't work" inasmuch as it tries to
provide an end-to-end feature using a hop-by-hop signalling method. it
should have been punted into EDNS1 along with RRD and the others.)
2. treatment of an unrecognized OPTION-CODE shall be the same as treatment
of a non-zero "Z" field, which is, to ignore it. (we ought not have to
increment VERSION when allocating new OPTION-CODE values.)
3. change 5.3 as follows. old:
5.3. Responders who do not understand these protocol extensions are
expected to send a response with RCODE NOTIMPL, FORMERR, or
SERVFAIL. ...
new:
5.3. Responders who do not understand these protocol extensions are
expected to send a response with RCODE NOTIMPL, FORMERR, or
SERVFAIL, or to appear to "time out" due to inappropriate action
by a "middle box" such as a NAT. ...
old:
... Therefore use of extensions should be "probed" such that
a responder who isn't known to support them be allowed a retry with
no extensions if it responds with such an RCODE. ...
new:
... Therefore use of extensions should be "probed" such that
a responder who isn't known to support them be allowed a retry with
no extensions if it responds with such an RCODE, or does not respond.
...
4. a response should only contain an OPT RR if the request contained one.
while #3 above reflects implementation experience, it was foreseeable and
thus qualifies as an editorial error on my part in the original draft. #1,
#2, and #4 are just editorial errors.
is there controversy around any of these, or, are there other things also
in need of clarification or correction from RFC 2671?
--
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: <http://ops.ietf.org/lists/namedroppers/>