Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

[Russ Housley <housley at vigilsec.com>]

Bob:

Insanity?  I think not.  Maybe you made the comment to get me post to 
this thread.  If so, it worked.

You are missing a few things that I consider to be relevant and important.

- We're talking about rfc2821bis (not RFC 2821 or RFC 821).

- The examples in RFC 821 use different domains from the ones in RFC 2821.

If the document were being advanced to Draft Standard with no changes 
at all, then I think it would be unreasonable to anyone ask for a 
change to address this issue.  However, other changes were deemed 
necessary.  Given that situation, it seems appropriate to consider 
current guidance.  This guidance is referenced in the appeal. The I-D 
Checklist (IDnits, http://www.ietf.org/ID-Checklist.html), Section 6, says:

    Addresses used in examples SHOULD preferably use
    fully qualified domain names instead of literal IP
    addresses, and preferably use example fqdn's such as
    foo.example.com instead of real-world fqdn's.

RFC 2119 has a pretty clear definition of "SHOULD".  It says:

    This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

This document uses "isif.usc.edu" and "postel at isi.edu" as 
examples.  The authors want to leave these as a  tribute to 
Jon.  FineFrom ietf-bounces at ietf.org  Wed Jun 18 19:41:50 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 66D993A6967;
	Wed, 18 Jun 2008 19:41:50 -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 DB49C3A6967
	for <ietf at core3.amsl.com>; Wed, 18 Jun 2008 19:41:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -92.198
X-Spam-Level: 
X-Spam-Status: No, score=-92.198 tagged_above=-999 required=5
	tests=[AWL=-9.600, BAYES_00=-2.599, URIBL_BLACK=20,
	USER_IN_WHITELIST=-100, WHOIS_NETSOLPR=0.001]
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 LiCLS4qBUHGX for <ietf at core3.amsl.com>;
	Wed, 18 Jun 2008 19:41:47 -0700 (PDT)
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152])
	by core3.amsl.com (Postfix) with SMTP id 9146C3A6938
	for <ietf at ietf.org>; Wed, 18 Jun 2008 19:41:47 -0700 (PDT)
Received: (qmail 10109 invoked by uid 0); 19 Jun 2008 02:42:24 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (207.168.80.186)
	by woodstock.binhost.com with SMTP; 19 Jun 2008 02:42:24 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 18 Jun 2008 22:35:59 -0400
To: bob.hinden at nokia.com,ietf at ietf.org
From: Russ Housley <housley at vigilsec.com>
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis 
In-Reply-To: <C122F91B-59B0-49AC-ABBC-6752217C4E47 at NOKIA.COM>
References: <8832006D4D21836CBE6DB469 at klensin-asus.vbn.inter-touch.net>
	<485590E2.3080107 at gmail.com>
	<p06250116c47c330c7dd0 at [75.145.176.242]>
	<4856DE3A.3090804 at gmail.com>
	<C122F91B-59B0-49AC-ABBC-6752217C4E47 at NOKIA.COM>
Mime-Version: 1.0
Message-Id: <20080619024147.9146C3A6938 at core3.amsl.com>
Cc: iesg 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

Bob:

Insanity?  I think not.  Maybe you made the comment to get me post to 
this thread.  If so, it worked.

You are missing a few things that I consider to be relevant and important.

- We're talking about rfc2821bis (not RFC 2821 or RFC 821).

- The examples in RFC 821 use different domains from the ones in RFC 2821.

If the document were being advanced to Draft Standard with no changes 
at all, then I think it would be unreasonable to anyone ask for a 
change to address this issue.  However, other changes were deemed 
necessary.  Given that situation, it seems appropriate to consider 
current guidance.  This guidance is referenced in the appeal. The I-D 
Checklist (IDnits, http://www.ietf.org/ID-Checklist.html), Section 6, says:

    Addresses used in examples SHOULD preferably use
    fully qualified domain names instead of literal IP
    addresses, and preferably use example fqdn's such as
    foo.example.com instead of real-world fqdn's.

RFC 2119 has a pretty clear definition of "SHOULD".  It says:

    This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

This document uses "isif.usc.edu" and "postel at isi.edu" as 
examples.  The authors want to leave these as a  tribute to 
Jon.  Fine.  I thi.  I think the implications of these are well understood.

This document also uses "foo.com", "foo.org", "bar.org", "foo-u.edu", 
and "generic.com" in examples.  I have not heard anyone offer "valid 
reasons" for using them instead of the ones in BCP 37.  I have heard 
people say that they are not causing harm.  That is not the same.  We 
have seen examples that use real IP addresses and domain names cause 
harm.  The excessive traffic sent to one NTP server comes to mind.

The IESG has been using DISCUSS positions since before 2003 to remove 
real domain names.  I'm sure that some have slipped through.  A 
couple have been pointed out in this thread.

So, Bob, the situation is not as simple as your message might indicate.

Russ

At 12:44 PM 6/18/2008, Bob Hinden wrote:
>Hi,
>
>Let me see if I understand this.
>
>- This is the specification for SMTP.  It's was first used on the
>Arpanet.
>
>- It is probably as widely deployed as IP and TCP.  Maybe more so.
>
>- It works (e.g., the email discussing this thread was sent via SMTP).
>
>- The IETF is now advancing it to Draft Standard.  I assume this means
>that we now have enough implementation experience.
>
>- Now the IESG doesn't want to approve it for Draft Standard because
>it is using a different set of example domains instead of the official
>IETF ones.
>
>Am I the only one who sees the insanity here?
>
>Bob

_______________________________________________
IETF mailing list
IETF at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


nk the implications of these are well understood.

This document also uses "foo.com", "foo.org", "bar.org", "foo-u.edu", 
and "generic.com" in examples.  I have not heard anyone offer "valid 
reasons" for using them instead of the ones in BCP 37.  I have heard 
people say that they are not causing harm.  That is not the same.  We 
have seen examples that use real IP addresses and domain names cause 
harm.  The excessive traffic sent to one NTP server comes to mind.

The IESG has been using DISCUSS positions since before 2003 to remove 
real domain names.  I'm sure that some have slipped through.  A 
couple have been pointed out in this thread.

So, Bob, the situation is not as simple as your message might indicate.

Russ

At 12:44 PM 6/18/2008, Bob Hinden wrote:
>Hi,
>
>Let me see if I understand this.
>
>- This is the specification for SMTP.  It's was first used on the
>Arpanet.
>
>- It is probably as widely deployed as IP and TCP.  Maybe more so.
>
>- It works (e.g., the email discussing this thread was sent via SMTP).
>
>- The IETF is now advancing it to Draft Standard.  I assume this means
>that we now have enough implementation experience.
>
>- Now the IESG doesn't want to approve it for Draft Standard because
>it is using a different set of example domains instead of the official
>IETF ones.
>
>Am I the only one who sees the insanity here?
>
>Bob

_______________________________________________
IETF mailing list
IETF at ietf.org
https://www.ietf.org/mailman/listinfo/ietf