Re: [apps-discuss] Applicability Statements

Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 12 May 2011 14:31 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C335E06A1 for <apps-discuss@ietfa.amsl.com>; Thu, 12 May 2011 07:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujVpeHKQUaob for <apps-discuss@ietfa.amsl.com>; Thu, 12 May 2011 07:31:35 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1520CE06C8 for <apps-discuss@ietf.org>; Thu, 12 May 2011 07:31:33 -0700 (PDT)
Received: (qmail invoked by alias); 12 May 2011 14:31:32 -0000
Received: from h87.s239.verisign.com (EHLO [10.131.32.72]) [216.168.239.87] by mail.gmx.net (mp014) with SMTP; 12 May 2011 16:31:32 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18e4D1V80IeQEQvZiu6vsq9pGf/jTFl+d9ZuP1f5H kV6zZTHDyEsTnz
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
In-Reply-To: <4DCAC1CB.3050905@qualcomm.com>
Date: Thu, 12 May 2011 17:31:29 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F5978D0-C48E-4B15-81E9-B33E430211E2@gmx.net>
References: <4DCAC1CB.3050905@qualcomm.com>
To: Pete Resnick <presnick@qualcomm.com>
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2011 14:31:39 -0000

Hi Pete, 

I do not find this effort useful and see it as a waste of time. Sorry to say that. 
I believe you should let the application area spend more time with relevant technical work rather than letting them spend time with process aspects. 

Ciao
Hannes

On May 11, 2011, at 8:05 PM, Pete Resnick wrote:

> At the IESG Retreat, we had a discussion on how we publish implementation advice, conformance specifications, protocol profiles, and the like. Right now, we often put these sorts of things in BCP or Informational documents. Unfortunately, these are both second class citizens in our document series: They don't get published as "standards" and they can't be reviewed and progressed along the standards track even though they often have information that we want to review for success.
> 
> There is a way to deal with these sorts of documents that we haven't tried in a very long time: RFC 2026 defines two kinds of standards track documents: Technical Specifications (TS), which we publish all of the time, and Applicability Statements (AS), which we haven't. According to 2026, an AS can be any of the following:
> 
>    "identifies the relevant TSs and the specific way in which they are to be combined"
>    "specify particular values or ranges of TS parameters or subfunctions of a TS protocol that must be implemented"
>    "specifies the circumstances in which the use of a particular TS is required, recommended, or elective"
>    "describe particular methods of using a TS in a restricted 'domain of applicability'"
>    "comprehensive conformance specification"
> 
> That sounds to me like exactly what we're trying to do. And an AS can be standards track, so long as it is at the same or lower maturity level than any of the TSs it references, so it can get full standards track treatment.
> 
> So, here's my proposal, which I've already gotten some positive feedback from the chairs of WGs that I cover in the apps area, and which the IESG has agreed to go along with: For my WGs in the apps area, we're going to try an informal experiment and submit documents like the above to the IESG for Proposed Standard AS. (I already have two such documents in mind: The potential MARF "BCP" and the the Malformed Header document.) Other ADs may join in, but I'll at least start the ball rolling. I'll try to get some early feedback from IESG folks as we get some I-Ds together to sanity check, and with any luck we'll get a few of these published as Proposed Standard. Then the IESG can talk about the criteria for advancement. However it works out, the worst case will be that we back off and publish these things as BCP or Informational instead, but I'm hopeful. After we get some experience, we'll see where else the use of AS might make sense.
> 
> What do folks think?
> 
> pr
> 
> -- 
> Pete Resnick<http://www.qualcomm.com/~presnick/>
> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss