RE: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
On Wed Jun 18 12:28:10 2008, Dave Cridland wrote:
> Therefore, to cover this particular case, such a blanket policy
> would have to be stated such that even vague recommendations in
> BCPs
I received a private comment which appeared to suggest I'm being
unclear here. So let me clarify:
The BCP, RFC 2606, as a whole is not a vague recommendation, and I
certainly didn't say that - the BCP states that the domains are
reserved, and, by its status as a BCP, it therefore reserves them.
(Donald Eastlake said elsewhere in the thread that the reason it's a
BCP at all was because the reservation of the domains needed the kind
of solid consensus that BCP status provides).
What is very much a vague recommendation is whether these domains
should be used.
The document says:
Depending on the nature of
the test or example, it might be best for it to be referencing a
TLD
permanently reserved for such purposes.
Yes, folks, that's "might be best" - hardly the eleventh commandment,
here.
And:
".example" is recommended for use in documentation or as
examples.
Note that both these, the latter of which is by far the strongest
recommendation in the document, refer to the rarely used ".exampleFrom ietf-bounces at ietf.org Wed Jun 18 13:23:00 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id D1E263A6A71;
Wed, 18 Jun 2008 13:23:00 -0700 (PDT)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id D01C03A6ADE
for <ietf at core3.amsl.com>; Wed, 18 Jun 2008 13:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.369
X-Spam-Level:
X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5
tests=[AWL=-0.246, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765,
HELO_MISMATCH_NET=0.611, RDNS_DYNAMIC=0.1]
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 77bXoLSiUljW for <ietf at core3.amsl.com>;
Wed, 18 Jun 2008 13:22:57 -0700 (PDT)
Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk
[217.155.137.60])
by core3.amsl.com (Postfix) with ESMTP id 48E5B3A6A71
for <ietf at ietf.org>; Wed, 18 Jun 2008 13:22:57 -0700 (PDT)
Received: from invsysm1 (shiny.isode.com [62.3.217.250]) by
turner.dave.cridland.net (submission)
via TCP with ESMTPA id <SFkAtQATl4VM at turner.dave.cridland.net> for
<ietf at ietf.org>; Wed, 18 Jun 2008 13:33:57 +0100
Subject: RE: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
References: =?US-ASCII?Q?=3D=3FUS-ASCII=3FQ=3F<8832006D4D21836CBE6D?=
=?US-ASCII?Q?469 at klensin-=3F=3D_=3D=3FUS-ASCII=3FQ=3Fus.vbn.inter-touc?=
=?US-ASCII?Q?.net><485590E2.3080107 at gmal=3F=3D_=3D=3FUS-ASCII=3FQ=3Fco?=
=?US-ASCII?Q?><p06250116c47c330c7dd0 at [75.145.176.242]=3F=3D?=
<4856DE3A.3090804 at gmail.com>
<049b01c8d089$6c901ce0$0a00a8c0 at CPQ86763045110>
<23618.1213785541.031305 at invsysm1>
<059901c8d132$d65df170$0a00a8c0 at CPQ86763045110>
<23618.1213788490.265871 at invsysm1>
In-Reply-To: <23618.1213788490.265871 at invsysm1>
MIME-Version: 1.0
Message-Id: <23618.1213792442.119204 at invsysm1>
Date: Wed, 18 Jun 2008 13:34:02 +0100
From: Dave Cridland <dave at cridland.net>
To: <ietf at ietf.org>
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org
On Wed Jun 18 12:28:10 2008, Dave Cridland wrote:
> Therefore, to cover this particular case, such a blanket policy
> would have to be stated such that even vague recommendations in
> BCPs
I received a private comment which appeared to suggest I'm being
unclear here. So let me clarify:
The BCP, RFC 2606, as a whole is not a vague recommendation, and I
certainly didn't say that - the BCP states that the domains are
reserved, and, by its status as a BCP, it therefore reserves them.
(Donald Eastlake said elsewhere in the thread that the reason it's a
BCP at all was because the reservation of the domains needed the kind
of solid consensus that BCP status provides).
What is very much a vague recommendation is whether these domains
should be used.
The document says:
Depending on the nature of
the test or example, it might be best for it to be referencing a
TLD
permanently reserved for such purposes.
Yes, folks, that's "might be best" - hardly the eleventh commandment,
here.
And:
".example" is recommended for use in documentation or as
examples.
Note that both these, the latter of which is by far the strongest
recommendation in the document, refer to the rarely used ".example"
TLD.
On the subject of the more traditionally used second-level domains,
it says only this:
The Internet Assigned Numbers Authority (IANA) also currently has
the
following second level domain names reserved which can be used as
examples.
So to summarize, if the IESG were saying that this phrasing forms a
policy that all technical specifications MUST only use the domains
from RFC 2606 - not that it is, but if it were, it would seem odd
that the outcome would be that the IESG would recommend the second
level domains in Section 3, rather than the TLD which seems to have
been more strongly recommended in the consensus backed document that
the IESG would be citing.
But that's not the point here, really - there is no such documented
policy, and the policy we don't have is quite clearly not specified
in the BCP that doesn't define it. At best, the BCP which does not
define the policy we don't have suggests a different policy we don't
have either would be a better policy to have, yet this alternate
policy is not, as far as I can tell, what the community would
generally want - so it's actually quite lucky that neither policy the
BCP doesn't define actually exists.
I hope that's clearer now.
Dave.
--
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
IETF mailing list
IETF at ietf.org
https://www.ietf.org/mailman/listinfo/ietf
"
TLD.
On the subject of the more traditionally used second-level domains,
it says only this:
The Internet Assigned Numbers Authority (IANA) also currently has
the
following second level domain names reserved which can be used as
examples.
So to summarize, if the IESG were saying that this phrasing forms a
policy that all technical specifications MUST only use the domains
from RFC 2606 - not that it is, but if it were, it would seem odd
that the outcome would be that the IESG would recommend the second
level domains in Section 3, rather than the TLD which seems to have
been more strongly recommended in the consensus backed document that
the IESG would be citing.
But that's not the point here, really - there is no such documented
policy, and the policy we don't have is quite clearly not specified
in the BCP that doesn't define it. At best, the BCP which does not
define the policy we don't have suggests a different policy we don't
have either would be a better policy to have, yet this alternate
policy is not, as far as I can tell, what the community would
generally want - so it's actually quite lucky that neither policy the
BCP doesn't define actually exists.
I hope that's clearer now.
Dave.
--
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
IETF mailing list
IETF at ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
