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

Marshall Eubanks <> Tue, 17 June 2008 18:43 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 7E3AA3A691D; Tue, 17 Jun 2008 11:43:53 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B1753A6A4A; Tue, 17 Jun 2008 11:43:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.473
X-Spam-Status: No, score=-103.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LSQueZHdFRR4; Tue, 17 Jun 2008 11:43:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C27443A691D; Tue, 17 Jun 2008 11:43:49 -0700 (PDT)
Received: from [] (account marshall_eubanks HELO [IPv6:::1]) by (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 11795054; Tue, 17 Jun 2008 14:44:34 -0400
Message-Id: <>
From: Marshall Eubanks <>
In-Reply-To: <049b01c8d089$6c901ce0$0a00a8c0@CPQ86763045110>
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
Date: Tue, 17 Jun 2008 14:44:33 -0400
References: <><><p06250116c47c330c7dd0@[]> <> <049b01c8d089$6c901ce0$0a00a8c0@CPQ86763045110>
X-Mailer: Apple Mail (2.924)
Cc: 'Pete Resnick' <>, 'John C Klensin' <>,,
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

I fully agree with Debbie here.

Human experience teaches us that examples will
be used, over time. is a commercial site. If the IETF uses in email examples,
it is reasonable to assume that will get unwanted traffic  
because of that. I think that
the IETF should not put itself in the position of causing avoidable  
pain to others, even if the likelihood of serious harm is small. Since  
there is a remedy, and it could be adopted readily, I think that the
discuss was reasonable and do not support the appeal.


On Jun 17, 2008, at 10:50 AM, Debbie Garside wrote:

> Not being a expert on this but having briefly read the documents in
> question, I agree with Brian.  This is not editorial. I would also  
> add that
> to go against an IETF BCP on the grounds of "well we have done so  
> already
> historically" does not make an argument for continuing to do so;  
> errors
> should be corrected when found, not endorsed.  If we are to pick and  
> choose
> which RFC's/BCP's we will take notice of what is the point of
> standardization? On the face of things, and with my little  
> knowledge, I
> would say that the person within the IESG who has invoked the  
> quite correct.
> Feel free to try to change my mind.
> Best regards
> Debbie Garside
>> -----Original Message-----
>> From: [] On
>> Behalf Of Brian E Carpenter
>> Sent: 16 June 2008 22:42
>> To: Pete Resnick
>> Cc: John C Klensin;;
>> Subject: Re: Appeal against IESG blocking DISCUSS on
>> draft-klensin-rfc2821bis
>> Pete (and Dave Crocker),
>> On 2008-06-17 03:20, Pete Resnick wrote:
>>> On 6/16/08 at 10:00 AM +1200, Brian E Carpenter wrote:
>>>> I think one can make a case that in some documents, use of
>>>> non-RFC2606 names as examples is a purely stylistic
>> matter, and that
>>>> in others, it would potentially cause technical confusion.
>>> Please make that case if you would, because the example you give:
>>>> In the evaluation record for what became RFC4343
>>>> ( we find:
>>>> "Editorial issues:
>>>> - the document uses a number of
>>>>   addresses/names, but in this case this seems justifiable"
>>>> In other words this *was* a judgement call.
>>> ...quite specifically said it was an "Editorial issue".
>> Please explain
>>> the circumstance in which it would not be an editorial issue.
>> Well, I've seen *many* cases of disagreement whether a
>> particular issue was editorial or substantative, so I
>> wouldn't claim that there is any absolute standard here. And
>> I've been trying not to comment on the specific issue of
>> 2821bis, because I have not reviewed it in detail and make no
>> claim to expertise. Nor am I commenting on whether the
>> specific DISCUSS comments in this case are reasonable or not
>> and whether they are well-formulated or not.
>> If a real domain name, or a real IP address, or a real IP
>> prefix, is used as an example in code, pseudo-code, or in the
>> description of a configuration mechanism, there's a good
>> chance that it will end up in an actual implementation or in
>> an actual configuration file one day (far from the IETF). In
>> my opinion that is a source of technical confusion and
>> possibly of unwanted traffic. So I think there is a strong
>> argument that RFC 2606 values SHOULD be used whenever
>> reasonably possible.
>> That's my opinion; I'm not asserting that it's an IETF
>> consensus or that it necessarily applies to 2821bis. But I do
>> assert that it's a technical argument and not an editorial one.
>>   Brian
>>> Of course, the ballot in this particular case
>>> <> makes
>> no claims
>>> about "technical confusion". I assume that when no
>> "technical confusion"
>>> exists, you *would* consider such things "an editorial issue"? (A
>>> misplaced comma or the use of the passive *may* cause "technical
>>> confusion", but unless this is called out, the assumption is always
>>> that such things are "editorial issues".)
>>> pr
>> _______________________________________________
>> IETF mailing list
> _______________________________________________
> IETF mailing list

IETF mailing list