Re: [dnsext] Last Call: <draft-ietf-dnsext-rfc2671bis-edns0-09.txt> (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From Section 7 of the draft:

 "Responders which choose not to implement the protocol extensions
  defined in this document MUST respond with a return code (RCODE) of
  FORMERR to messages containing an OPT RR in the additional section
  and MUST NOT include an OPT record in the response."

That looks like a change [1] to STD 13. Responders which respond with a return code of 4 would not be compliant.

On publication of draft-ietf-dnsext-rfc2671bis-edns0-09, will it be part of STD 13?

From RFC 3225:

  "In the event a server returns a NOTIMP, FORMERR or SERVFAIL response
   to a query that has the DO bit set, the resolver SHOULD NOT expect
   DNSSEC security RRs and SHOULD retry the query without EDNS0 in
   accordance with section 5.3 of [RFC2671]."

There's a normative reference [2] to that RFC in this draft.

In Section 1:

 "This document deprecates Extended Labels, and therefore Binary Labels,
   obsoleting [RFC2673]."

draft-ietf-dnsext-rfc6195bis-04 mentions that:

 "The Binary label type is Historic [RFC2671bis]."

The IETF might wish to consider whether it is necessary to align the text in the two drafts.

Regards,
-sm

1. Whether it is a change or not depends upon how one reads RFC 6410. The write-up mentions that there are no unused features in the specification that greatly increase implementation complexity. It is unclear whether this document is a minor revision of RFC 2671.

2. http://www.ietf.org/mail-archive/web/weirds/current/msg01668.html



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]