Return-Path: <jason_livingood@cable.comcast.com>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
 with ESMTP id E83FB28C126 for <dnsop@core3.amsl.com>;
 Mon, 13 Jul 2009 06:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.582
X-Spam-Level: *
X-Spam-Status: No, score=1.582 tagged_above=-999 required=5 tests=[AWL=-1.419,
 BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368,
 HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u05lKLViHZtq for
 <dnsop@core3.amsl.com>; Mon, 13 Jul 2009 06:55:24 -0700 (PDT)
Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com
 [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id F3F5628C2E5 for
 <dnsop@ietf.org>; Mon, 13 Jul 2009 06:55:23 -0700 (PDT)
Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP
 id KP-TDCH7.65140412; Mon, 13 Jul 2009 09:55:35 -0400
Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by
 PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959);
 Mon, 13 Jul 2009 09:55:36 -0400
Received: from 198.137.252.126 ([198.137.252.126]) by
 PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server
 webmail.comcast.com ([198.137.252.76]) with Microsoft Exchange Server
 HTTP-DAV ; Mon, 13 Jul 2009 13:55:34 +0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Mon, 13 Jul 2009 09:55:42 -0400
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>, <dnsop@ietf.org>
Message-ID: <C680B51E.EB21%Jason_Livingood@cable.comcast.com>
Thread-Topic: [DNSOP] Review of draft-livingood-dns-redirect-00
Thread-Index: AcoCg8EFpe0+cg9sRROXjQqBj7pXcwBPdtQy
In-Reply-To: <p062408b6c67ed70acc85@[10.20.30.158]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3330323743_387809"
X-OriginalArrivalTime: 13 Jul 2009 13:55:36.0210 (UTC)
 FILETIME=[98E38720:01CA03C1]
Subject: Re: [DNSOP] Review of draft-livingood-dns-redirect-00
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
 <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
 <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jul 2009 13:55:28 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3330323743_387809
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Good guidance on Informational vs. BCP.  We may get there eventually, but I
thought that starting as a draft BCP might provoke more detailed and useful
debate.  ;-)

On the topic of =8Clying resolvers=B9 though, that seems a bit strong IMHO.  Bu=
t
perhaps I have missed a strong MUST statement (per RFC 2119) in a relevant
RFC that you could refer me to?

Jason


On 7/11/09 7:59 PM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:

> It seems inappropriate for the IETF to bless lying resolvers as a Best Cu=
rrent
> Practice. I doubt we as a community could have consensus on when lying is
> good, when it is neutral, and when it is bad. Without such agreement, we =
can't
> agree on how to run such servers. Having said that, the publication of a
> document such as this (with more input from the community) as a Informati=
onal
> RFC could indeed help the Internet.
>=20
> --Paul Hoffman, Director
--VPN Consortium

--B_3330323743_387809
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [DNSOP] Review of draft-livingood-dns-redirect-00</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Good guidance on Informational vs. BCP. &nbsp;We may get there eventually,=
 but I thought that starting as a draft BCP might provoke more detailed and =
useful debate. &nbsp;;-)<BR>
<BR>
On the topic of &#8216;lying resolvers&#8217; though, that seems a bit stro=
ng IMHO. &nbsp;But perhaps I have missed a strong MUST statement (per RFC 21=
19) in a relevant RFC that you could refer me to? &nbsp;<BR>
<BR>
Jason<BR>
<BR>
<BR>
On 7/11/09 7:59 PM, &quot;Paul Hoffman&quot; &lt;<a href=3D"paul.hoffman@vpnc=
.org">paul.hoffman@vpnc.org</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>It seems inappropriate for the IETF to bless lyi=
ng resolvers as a Best Current Practice. I doubt we as a community could hav=
e consensus on when lying is good, when it is neutral, and when it is bad. W=
ithout such agreement, we can't agree on how to run such servers. Having sai=
d that, the publication of a document such as this (with more input from the=
 community) as a Informational RFC could indeed help the Internet.<BR>
<BR>
--Paul Hoffman, Director<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'>--VPN Consortium</SPAN></FONT>
</BODY>
</HTML>


--B_3330323743_387809--

