Re: [apps-discuss] Review of draft-ietf-appsawg-rfc3536bis-04

SM <sm@resistor.net> Sat, 02 July 2011 08:15 UTC

Return-Path: <sm@resistor.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 0735A21F8844 for <apps-discuss@ietfa.amsl.com>; Sat, 2 Jul 2011 01:15:01 -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 xfdXqElbQcp3 for <apps-discuss@ietfa.amsl.com>; Sat, 2 Jul 2011 01:14:58 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C66621F8842 for <apps-discuss@ietf.org>; Sat, 2 Jul 2011 01:14:58 -0700 (PDT)
Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p628EnMp027147; Sat, 2 Jul 2011 01:14:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1309594495; bh=unSLzvD9upX+mjh5TW/S95Jb33lcfN8At+hO2JuJpYs=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=aonXLeRL9e4HnXL3OkidUTci3d8UKM7ls2SjBu5qQ6FyH4z8/aLNuzaKJTIxmvjT0 iWpA6d3KjVGASE7ojbVdbq3RSVAIlJJbAQJg8PbSnN/4f0kWuYA6Co4OttVOrxIzbB 2xoijdZYTuLCfxj98+9Tb9OfEg4OLf8aNZNVO4C8=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1309594495; bh=unSLzvD9upX+mjh5TW/S95Jb33lcfN8At+hO2JuJpYs=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=T2zd008e1li8uVtKg41lmok1LABdUye8NTFxNh28cqpIASv0XfqhhQPFX1hFG/aif m7sK4NG6bUL1KBMG93UgNqvkHsRUvxQY34e93/SBfcqJYHxKQCnzGCB2DcEgOf17Sv rFE+svZ5K7qTc3FOZAXya2hwxUrZB4HpHGUbkN94=
Message-Id: <6.2.5.6.2.20110701233438.0272df28@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 02 Jul 2011 01:10:24 -0700
To: apps-discuss@ietf.org
From: SM <sm@resistor.net>
In-Reply-To: <4E0E82D0.6040003@qualcomm.com>
References: <20110701162416.GB24564@shinkuro.com> <148089D7A073E8A4A9F54B64@PST.JCK.COM> <4E0E82D0.6040003@qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: Paul Hoffman <phoffman@imc.org>
Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-rfc3536bis-04
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: Sat, 02 Jul 2011 08:15:01 -0000

At 19:30 01-07-2011, Pete Resnick wrote:
>As I have mentioned to Paul offline, there was some pretty stiff 
>pushback on this being BCP. Some of it was of the form, "You haven't 
>said it strongly enough" (like Dan's DISCUSS comment, where he and 
>others would *prefer* this document to be a BCP), and I think with 
>some changes, those folks are right on board. There are other ADs 
>(nominally Russ, though there are others who support his position) 
>who felt that in no event was a glossary the appropriate sort of 
>thing for BCP status; it is replacing an existing Informational 
>document, and it isn't clear that glossaries are appropriate for 
>BCPs. RFC 2026 is not at all precise on this; the only category of 
>BCP this could really fall under is if this is meant to "document 
>the operation of the IETF itself", which means to me that it is a 
>"documentation procedure" (i.e., "we shall use these definitions"). 
>The IETF has a perfectly mixed record on whether glossaries are BCP 
>Informational, so precedents are unclear, the extremes being RFC 
>2119 (a BCP that defined several terms for use in IETF documents as 
>normative protocol interoperability statements) and RFC 2828 (an 
>Informational document that has a nice list of security terms and 
>their definitions, but their use is strictly informational).

Section 1.1 mentions the following as one of the purposes of the document:

   "The definitions here should be used by IETF standards that want to use
    them. IETF standards that explicitly want to create different
    definitions for the terms defined here can do so, but the terms here
    should be considered the default for IETF standards after the time of
    publication of this document.  Some of the definitions in this
    document come from many earlier IETF documents and books."

Would rewriting the above as:

   "The definitions here SHOULD be used by IETF standards that want to use
    them. IETF standards that explicitly want to create different
    definitions for the terms defined here can do so, but the terms here
    MUST be considered the default for IETF standards after the time of
    publication of this document.  Some of the definitions in this
    document come from many earlier IETF documents and books."

make this BCP material?

The purpose of BCP 161 is to provide a definition of a term for use 
in all future IETF documents that refer to the term.  The difference 
between that BCP and this draft is that the title does not say 
"Guidelines".  BCP are meant to express community consensus.  In 
other words, it can be view as "these are the terms that have been 
used in discussions about internationalization; and the IETF agrees 
that these terms are the default as from the date of publication of this draft.

If a test was required to determine whether the draft should qualify 
as BCP, I suggest the following:

   Is there disagreement in the IETF community on the definitions used?

   Is there a sense of rough agreement in the internationalization
   community on the definitions used?

The last question is to avoid a disconnect between the IETF and reality.

The DISCUSS raised by Dan Romascanu could be addressed by having 
Section 1.1 cover what has changed since RFC 3536.

BTW, "IETF members" (Section 6) should be changed to "IETF participants".

As it (the draft) stands, I don't see a strong case for a fight about 
the intended status.

Regards,
-sm