IETF Logo Mail Archive

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

SM <sm@resistor.net> Wed, 03 October 2012 07:16 UTC

Return-Path: <sm@resistor.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D31A21F86AB for <ietf@ietfa.amsl.com>; Wed, 3 Oct 2012 00:16:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.593
X-Spam-Level:
X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rt-mKyVoV+ht for <ietf@ietfa.amsl.com>; Wed, 3 Oct 2012 00:16:14 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9817021F865B for <ietf@ietf.org>; Wed, 3 Oct 2012 00:16:14 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q937G9NG008447 for <ietf@ietf.org>; Wed, 3 Oct 2012 00:16:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1349248573; bh=+pf//ijI++OP+WXf/kxVw34/eupUbXQpV7WHiJ2nKso=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=fBvHSweNEapeWd2ccKIAZv9Bwq6URlb19r28l+zkJhj8RUtPRql0sJIrsfc2CZnhZ 1OWIe5N56CuH4OwrB7cJb7hmiV5Jk9meyvkqpE/yz5yiJajpW1fLU0kKxXwptzT3GZ YWytXON0OEVCuNE1kwWl8YFZFsBAOHf/aJbgwN7g=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1349248573; i=@resistor.net; bh=+pf//ijI++OP+WXf/kxVw34/eupUbXQpV7WHiJ2nKso=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=yhWhoO9vXYABOwuEspv9/GIOSLsLb1tm36mqUnpAXkHWgObcnaYgoBJ3EKG/pk6Ts LW91RFccTQkl5KwUxokg+ev4ZMB83Mo3L0NGqC3knWPq/XI4hiI40fT6nRltpdXPsv 5rzIaFgry6Kt8g8NMjEw6+ogdoAiAJIV3+sDULGg=
Message-Id: <6.2.5.6.2.20121002215133.0a563910@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 02 Oct 2012 23:39:20 -0700
To: ietf@ietf.org
From: SM <sm@resistor.net>
Subject: Re: [dnsext] Last Call: <draft-ietf-dnsext-rfc2671bis-edns0-09.txt> (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
In-Reply-To: <506B6BE9.2000805@ogud.com>
References: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> <56DB6FE506A144D1183B93A8@JcK-HP8200.jck.com> <506B01D1.9080708@ogud.com> <8F3DCBA9A3AF566810CD1061@JcK-HP8200.jck.com> <506B6BE9.2000805@ogud.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Oct 2012 07:16:15 -0000

 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

v2.23.0 | Report a Bug | By Email