Re: [yam] Referencing 1652bis and update to RFC 5321/5322
John C Klensin <john-ietf@jck.com> Mon, 28 June 2010 14:24 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: yam@core3.amsl.com
Delivered-To: yam@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA95A3A6891 for <yam@core3.amsl.com>; Mon, 28 Jun 2010 07:24:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.365
X-Spam-Level:
X-Spam-Status: No, score=-0.365 tagged_above=-999 required=5 tests=[AWL=-0.366, BAYES_50=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 D0LN7t2v3N9I for <yam@core3.amsl.com>; Mon, 28 Jun 2010 07:24:18 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 37B243A6875 for <yam@ietf.org>; Mon, 28 Jun 2010 07:24:18 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OTFG6-000BK5-4b; Mon, 28 Jun 2010 10:24:26 -0400
Date: Mon, 28 Jun 2010 10:24:25 -0400
From: John C Klensin <john-ietf@jck.com>
To: S Moonesamy <sm+ietf@elandsys.com>, yam@ietf.org
Message-ID: <E8D8B0D5CAFD2704FF5D7DB5@PST.JCK.COM>
In-Reply-To: <6.2.5.6.2.20100628022327.0add5e10@resistor.net>
References: <6.2.5.6.2.20100626145920.0b610618@elandnews.com> <6785AF47EC3ACD933037ABE5@PST.JCK.COM> <6.2.5.6.2.20100626173821.0b374a90@resistor.net> <4C2725DA.6000507@isode.com> <4C27F351.9060604@att.com> <6.2.5.6.2.20100628022327.0add5e10@resistor.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: [yam] Referencing 1652bis and update to RFC 5321/5322
X-BeenThere: yam@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Yet Another Mail working group discussion list <yam.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/yam>
List-Post: <mailto:yam@ietf.org>
List-Help: <mailto:yam-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Jun 2010 14:24:20 -0000
--On Monday, June 28, 2010 03:19 -0700 S Moonesamy <sm+ietf@elandsys.com> wrote: > At 20:22 27-06-10, John C Klensin wrote: >> Per my earlier note, if the WG is going to go down that path, >> I think it is important to distinguish between: >> >> (1) In need of a rev because of specific issues that >> require clarification. >> >> (2) In need of a rev because the document itself is >> sufficiently defective that it requires a complete >> revision and replacement. > > Some of the issues are more or less clarifications instead of > the defects. There is one issue (#22) listed as an > interperability problem. > >> queue only because we had to promise them to IESG members for >> the Full Standard version in order to get 5321 signed off. If >> the IESG makes "Full Standard version" meaningless, there >> should be no need to do that work. > > There is also an impact on substantial parts of the current > charter. If this is turned into document updates to the email > specifications, it might end up being contentious. > > If and only if people are still interested in updating some of > the documents, what should be the scope of the work? Let's turn this around. One of the attractions of the "pre-evaluation" model as it has evolved is independent of the agreement with the IESG. As an editor, I have a list of changes the WG wants me to make (or at least that someone in the WG has proposed to make) and know that I can focus my editing time in those areas, rather than expecting to go back and forth (potentially endlessly) about what is supposed to be done. If we are now moving in the direction of "no full standards under the current rules" then the pre-eval documents need to be reviewed --both within the WG and potentially with the IESG as to what standing they have. In particular, if things change to new definitions of maturity levels (independent of how many of them there are), the assumptions under which the pre-eval documents were constructed become more or less irrelevant. If those documents are going to continue to have value under those circumstances, we would presumably need to go back and rethink them and what they mean. While I'm happy to have the actual discussion in Maastricht, is it reasonable to suggest that we simply stop substantive work until the issue is resolved? One way to interpret the Housley draft (and I can't tell whether it has support from within the IESG or not), is that we are wasting our time. If so... regards, john
- [yam] Referencing 1652bis and update to RFC 5321/… Alexey Melnikov
- Re: [yam] Referencing 1652bis and update to RFC 5… Dave CROCKER
- Re: [yam] Referencing 1652bis and update to RFC 5… Alexey Melnikov
- Re: [yam] Referencing 1652bis and update to RFC 5… Dave CROCKER
- Re: [yam] Referencing 1652bis and update to RFC 5… Alessandro Vesely
- Re: [yam] Referencing 1652bis and update to RFC 5… John C Klensin
- Re: [yam] Referencing 1652bis and update to RFC 5… Tony Hansen
- Re: [yam] Referencing 1652bis and update to RFC 5… John C Klensin
- Re: [yam] Referencing 1652bis and update to RFC 5… S Moonesamy
- Re: [yam] Referencing 1652bis and update to RFC 5… John C Klensin
- Re: [yam] Referencing 1652bis and update to RFC 5… Ned Freed
- Re: [yam] Referencing 1652bis and update to RFC 5… S Moonesamy
- Re: [yam] Referencing 1652bis and update to RFC 5… Jari Arkko
- Re: [yam] Referencing 1652bis and update to RFC 5… Alessandro Vesely
- Re: [yam] Referencing 1652bis and update to RFC 5… Jari Arkko
- Re: [yam] Referencing 1652bis and update to RFC 5… John C Klensin
- Re: [yam] Referencing 1652bis and update to RFC 5… Ned Freed
- Re: [yam] Referencing 1652bis and update to RFC 5… Dave CROCKER
- Re: [yam] Referencing 1652bis and update to RFC 5… Tony Hansen
- Re: [yam] Referencing 1652bis and update to RFC 5… John C Klensin
- Re: [yam] Referencing 1652bis and update to RFC 5… Jari Arkko
- Re: [yam] Referencing 1652bis and update to RFC 5… John C Klensin
- Re: [yam] Referencing 1652bis and update to RFC 5… John C Klensin