Re: More new text for 2821bis
"Frank Ellermann" <nobody@xyzzy.claranet.de> Wed, 09 July 2008 08:50 UTC
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m698ow96039326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2008 01:50:59 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m698ow6P039325; Wed, 9 Jul 2008 01:50:58 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m698otNP039318 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-smtp@imc.org>; Wed, 9 Jul 2008 01:50:57 -0700 (MST) (envelope-from gis-ietf-smtp-979@gmane.org)
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KGVO0-0002t1-0I for ietf-smtp@imc.org; Wed, 09 Jul 2008 08:50:52 +0000
Received: from hmbg-d9b88e23.pool.mediaways.net ([217.184.142.35]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-smtp@imc.org>; Wed, 09 Jul 2008 08:50:51 +0000
Received: from nobody by hmbg-d9b88e23.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-smtp@imc.org>; Wed, 09 Jul 2008 08:50:51 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-smtp@imc.org
From: Frank Ellermann <nobody@xyzzy.claranet.de>
Subject: Re: More new text for 2821bis
Date: Wed, 09 Jul 2008 10:53:11 +0200
Organization: <http://purl.net/xyzzy>
Lines: 104
Message-ID: <g51u53$rpf$1@ger.gmane.org>
References: <20080707170001.ECC4A28C0F7@core3.amsl.com> <48729A1B.7030104@att.com> <0dy8Zj+lByglnd12S+8PFA.md5@lochnagar.oryx.com> <487368EA.1010500@isode.com> <BB5CD720FD8C6AF403D37453@p3.JCK.COM>
Reply-To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: hmbg-d9b88e23.pool.mediaways.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>
John C Klensin wrote: > However, while it is apparently not final and still has not > appeared in the tracker (see > https://datatracker.ietf.org/idtracker/draft-klensin-rfc2821bis/), > the apparent intent of the IESG, reflected in the ballot at > https://datatracker.ietf.org/idtracker/ballot/2471/, is to > add an IESG note to the front of the document That's how those RFC-editor and IESG notes are prepared, they appear in the (draft) approval mail at the end of the ballot. It is one of two weak points (the other being AUTH48) with drafts. But authors are free to reject it in AUTH48 by not signing an annotated draft. For RFC 4408 folks caught an "RFCed note" attempt to remove an absolutely critical NOT RECOMMENDED, and rejected it. After that it popped up again as "IESG note" and went to an IAB review. The IAB decided that conflicting experiments offering a convoluted IESG note "opt-out" for participants of the 1st experiment not interested in the 2nd experiment are no issue. With that on public record the case was closed and the RFC published (with the complete revised IESG note, see below). > the IESG has made no attempt to engage in a dialog on the > subject of whether a note or this sort should be added, or > about what it should contain Yes, interested folks have to check the proposed approval or read the final announcement, and they also have to check the final AUTH48 outcome. Even a good faith "RFC-editor note" can introduce massive side-effects like blocking RFCs 4645 and 4646 for many months until RFC 4647 was ready. > while Section 6.1.2 of RFC 2026 contains an extended > discussion of the IESG changing categories, forming WGs, > etc., it appears clear that the IESG is to "approve or > disapprove", not to start adding text reflecting its own > observations, observations that may or may not represent > community consensus. Did you ever read the rather long IESG note in RFC 4408 ? | there is no general technical consensus and efforts to | reconcile the two approaches have failed = After the WG had consensus that the two approaches are incompatible it was terminated in violation of RFC 2418 | these documents have not received full IETF review = a request for an IETF Last Call was rejected by the IESG | Note that the Sender ID experiment may use DNS records | that may have been created for the current SPF experiment | or earlier versions in this set of experiments. = Three Sender ID ABSTAINs failed to reach 1/3 for a DO NOT PUBLISH by one vote (IIRC) | Depending on the content of the record, this may mean that | Sender-ID heuristics would be applied incorrectly to a | message. Depending on the actions associated by the | recipient with those heuristics, the message may not be | delivered or may be discarded on receipt. = A 100% accurate description of the problem. | Participants relying on Sender ID experiment DNS records | are warned that they may lose valid messages in this set | of circumstances. = That is about receivers applying the Sender ID algorithm on an SPF polic; they may lose legit inbound mails. This statement apparently missed the point in two dimensions. | aParticipants publishing SPF experiment DNS records should | consider the advice given in section 3.4 of RFC 4406 and | may wish to publish both v=spf1 and spf2.0 records to avoid | the conflict. = Sender ID offers a weird "opt-out" from its own bugs; it is no problem to publish more than one TXT record; about a million (back in 2006) of existing SPF publishers will read IESG notes. The next eight lines are mostly unrelated to RFC 4408, they note that RFC 4406 can be not published on standards track "as is" due to interoperability issues with RFC 822 + 2822. (Among others, there are also issues with RFC 4409) The longest IESG note I've ever seen in IETF RFCs (exactly the same text went into RFCs 4405, 4406, and 4407). > Advice or instructions welcome. Readers will hopefully see that using real domains or mail addresses in examples is not recommended, as it can cause harm or other unexpected (SEO) effects. At some point in time, e.g., in a next 2026bis round, the "IESG notes" deserve a critical review. They are free to publish their thoughts in separate documents, unsolicited annotations sometimes annoy authors and interested users. Frank
- Response to appeal from John Klensin dated 13-Jun… IESG Secretary
- Re: More new text for 2821bis SM
- Re: More new text for 2821bis (was: Re: Response … ned+ietf-smtp
- Re: More new text for 2821bis (was: Re: Response … Chris Newman
- Re: Response to appeal from John Klensin dated 13… Chris Newman
- Re: More new text for 2821bis (was: Re: Response … John C Klensin
- Re: More new text for 2821bis (was: Re: Response … SM
- Re: More new text for 2821bis John C Klensin
- Re: More new text for 2821bis (was: Re: Response … John C Klensin
- Re: More new text for 2821bis Frank Ellermann
- Re: More new text for 2821bis (was: Re: Response … John C Klensin
- Re: More new text for 2821bis (was: Re: Response … John Leslie
- Re: Response to appeal from John Klensin dated 13… Tony Finch
- Re: More new text for 2821bis (was: Re: Response … SM
- Re: More new text for 2821bis (was: Re: Response … Pete Resnick
- Re: More new text for 2821bis Keith Moore
- Re: More new text for 2821bis John C Klensin
- Re: More new text for 2821bis Keith Moore
- Re: More new text for 2821bis Frank Ellermann
- More new text for 2821bis (was: Re: Response to a… John C Klensin
- Re: IESG response fixes for 2821bis SM
- Re: IESG response fixes for 2821bis Tony Hansen
- Re: borderline offtopic about examples Frank Ellermann
- Re: borderline offtopic about examples SM
- Re: borderline offtopic about examples Arnt Gulbrandsen
- Re: Response to appeal from John Klensin dated 13… Cyrus Daboo
- Re: Response to appeal from John Klensin dated 13… Francesco Gennai
- Re: Response to appeal from John Klensin dated 13… Francesco Gennai
- Re: IESG response fixes for 2821bis Tony Hansen
- Re: Response to appeal from John Klensin dated 13… John Leslie
- Re: Response to appeal from John Klensin dated 13… Alexey Melnikov
- Re: Response to appeal from John Klensin dated 13… Keith Moore
- Re: Response to appeal from John Klensin dated 13… Alessandro Vesely
- Re: borderline offtopic about examples Frank Ellermann
- Re: Response to appeal from John Klensin dated 13… Steve Atkins
- Re: IESG response fixes for 2821bis Frank Ellermann
- Re: borderline offtopic about examples John C Klensin
- Re: IESG response fixes for 2821bis John C Klensin
- borderline offtopic about examples Arnt Gulbrandsen
- Re: IESG response fixes for 2821bis Magnus Westerlund
- Re: Response to appeal from John Klensin dated 13… Hector Santos
- Re: Response to appeal from John Klensin dated 13… Arnt Gulbrandsen
- Re: IESG response fixes for 2821bis Frank Ellermann
- Re: Response to appeal from John Klensin dated 13… SM
- IESG response fixes for 2821bis Tony Hansen
- Re: Response to appeal from John Klensin dated 13… Keld Jørn Simonsen
- Re: Response to appeal from John Klensin dated 13… Dave Crocker
- Re: Response to appeal from John Klensin dated 13… ned+ietf-smtp
- Re: Response to appeal from John Klensin dated 13… Jim Fenton
- Re: Response to appeal from John Klensin dated 13… Tony Hansen