Re: [yam] Referencing 1652bis and update to RFC 5321/5322

S Moonesamy <sm+ietf@elandsys.com> Mon, 28 June 2010 17:31 UTC

Return-Path: <sm@elandsys.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 8064E3A698F for <yam@core3.amsl.com>; Mon, 28 Jun 2010 10:31:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.547
X-Spam-Level:
X-Spam-Status: No, score=-0.547 tagged_above=-999 required=5 tests=[AWL=-0.548, 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 Srk6pdNiME+t for <yam@core3.amsl.com>; Mon, 28 Jun 2010 10:30:53 -0700 (PDT)
Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id D0DE53A67F9 for <yam@ietf.org>; Mon, 28 Jun 2010 10:30:53 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.239.163]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id o5SHUqYO005375; Mon, 28 Jun 2010 10:30:58 -0700
Message-Id: <6.2.5.6.2.20100628074724.0c3ba0c0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 28 Jun 2010 10:10:17 -0700
To: John C Klensin <john-ietf@jck.com>
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <E8D8B0D5CAFD2704FF5D7DB5@PST.JCK.COM>
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> <E8D8B0D5CAFD2704FF5D7DB5@PST.JCK.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: yam@ietf.org
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 17:31:41 -0000

Hi John,
At 07:24 28-06-10, John C Klensin wrote:
>Let's turn this around.  One of the attractions of the

Before I delve into this, I'll remind the working group that Alexey 
asked a fundamental question (see 
http://www.ietf.org/mail-archive/web/yam/current/msg00509.html )

>"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.

In the (experimental) "pre-evaluation" model, the WG identifies a 
list issues before the actual document is edited.  Using Tony's 
words, this forces people to think.  It also keeps controversies in 
check.  The editor of the document gets an idea of what changes are 
being requested and the editing effort is focused on that.  This 
model has not been fully tested though.

I'll use the two current pre-evaluation I-Ds as examples.  In 
draft-ietf-yam-5321bis-smtp-pre-evaluation-05, there are five items 
listed as non-changes.  We have a rough idea of the outcome for the 
three errata.  There was five issues listed in Appendix B as 
editorial 
changes.  draft-ietf-yam-rfc5322bis-msgfmt-pre-evaluation-00 lists 
four errata, three of them about ABNF and the fourth is an editorial 
change.  The WG can open the actual documents and tell the editor 
what is supposed to be done.  The documents would take less WG time 
and the editors might only have to submit one or two I-Ds.

>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.

In a "no full standards" scenario, the pre-evaluation documents would 
have to be rewritten.  We could resort to amnesia and keep the 
current "rules".  But it won't have any standing on a Last Call.  The 
work would also have to be completed within the same IESG cycle.  And 
we also have to consider whether it is worth doing when maturity 
levels no longer have the same meaning.

>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...

This effort was started in Dublin in July 2008.  There was 
discussions within the WG and at the plenary at Hiroshima in November 
2009 about the effort.  Each time a non-WG process issue is sorted 
out, another one comes along.  The uncertainty is detrimental to the WG work.

The IESG is well aware of the work being carried out by this WG.  I 
don't know whether draft-housley-two-maturity-levels will gain 
consensus.  If it represents the view of the IESG, I'll take it as 
"don't bother doing this work".  The documents are "good enough".

All this shouldn't have occurred after two years of effort as this WG 
has been making some progress.  A charter is a contract between the 
IETF and the working group which is committing to meet explicit 
milestones and delivering specific "products".  It would be 
unreasonable of me to ask the reviewers and editors of the documents 
to carry substantive work if the contract is revoked in such a 
manner.  I mentioned the facts.  I'll leave it to the WG to determine 
whether it is a waste of time or not.

Regards,
S. Moonesamy