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

Pete Resnick <> Sat, 02 July 2011 02:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1BBD21F8D51 for <>; Fri, 1 Jul 2011 19:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.239
X-Spam-Status: No, score=-106.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qUMbJP6tvkmX for <>; Fri, 1 Jul 2011 19:30:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DF0A321F8D50 for <>; Fri, 1 Jul 2011 19:30:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1309573852; x=1341109852; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<>|Date:=20Fr i,=201=20Jul=202011=2021:30:40=20-0500|From:=20Pete=20Res nick=20<>|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv: |MIME-Version:=201.0|To:=20John=20C=20Klensin=20<john-iet>|CC:=20Andrew=20Sullivan=20<ajs@anvilwalrusden. com>,=20<>,=20Paul=0D=0A=20Hoffman =20<>|Subject:=20Re:=20[apps-discuss]=20R eview=20of=20draft-ietf-appsawg-rfc3536bis-04|References: =20<>=20<148089D7A073E 8A4A9F54B64@PST.JCK.COM>|In-Reply-To:=20<148089D7A073E8A4 A9F54B64@PST.JCK.COM>|Content-Type:=20text/plain=3B=20cha rset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1]; bh=SUB4iw2COcsX1ansbGuf/i98qTSLZVwRe4sXKrZCaoA=; b=OTqsldgW4ACaL/bS7bkEQLglaI7ht+xkU/JOx+l1NmP/OF+Tbp8WmKNx 7mds3Ov7pLjkX2A98Wecnz5Nr3iXieZjgWxHRvQbr9ZR1nF0wWEo93pI6 XrqinGDPuRMeXk70Rfd1C1a1pCWxAHbI2htO2ept0HPnGfEYlxwAEW21d 8=;
X-IronPort-AV: E=McAfee;i="5400,1158,6394"; a="101259448"
Received: from ([]) by with ESMTP; 01 Jul 2011 19:30:52 -0700
X-IronPort-AV: E=Sophos;i="4.65,461,1304319600"; d="scan'208";a="153156606"
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 01 Jul 2011 19:30:52 -0700
Received: from Macintosh-4.local ( by ( with Microsoft SMTP Server (TLS) id; Fri, 1 Jul 2011 19:30:43 -0700
Message-ID: <>
Date: Fri, 1 Jul 2011 21:30:40 -0500
From: Pete Resnick <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: John C Klensin <>
References: <> <148089D7A073E8A4A9F54B64@PST.JCK.COM>
In-Reply-To: <148089D7A073E8A4A9F54B64@PST.JCK.COM>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
Cc: Paul Hoffman <>,
Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-rfc3536bis-04
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 02 Jul 2011 02:30:53 -0000

On 7/1/11 3:00 PM, John C Klensin wrote:

> --On Friday, July 01, 2011 12:24 -0400 Andrew Sullivan
> <>  wrote:
>> Obviously, the draft can't constrain what other documents
>> might do. But it would be nice to encourage other documents,
>> if they're going to come up with different definitions, to use
>> different words.  If someone decided to re-define SHOULD at
>> the beginning of their standards document, we would quite
>> justifiably complain,&  I think the same goes here.  I suggest
>> the following additional sentence:
>>      IETF standards that want different definitions are
>> encouraged, for     clarity's sake, to find terms different to
>> the ones defined here.
> In drafts of this document up this stage, we have tried to
> preserve the informative/ descriptive/ persuasive tone of RFC
> 3536 while pushing in the direction I think you are encouraging.
> Some IESG members have pointed out that the document doesn't
> sound normative enough to be a BCP.  In retrospect, trying to
> circle around the issue (for which I am more to blame than Paul)
> was probably unwise.  Depending on what the IESG has to say
> (i.e., what Pete tells us), we are contemplating rewriting that
> explanation into RFC 2119 language and simply saying that these
> definitions SHOULD be used in IETF documents and that, if people
> choose to not use them, they MUST define the terms they are
> using exactly and preferably use terminology that does not
> overlap.

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

As I suggested, Paul has already written to the IESG some explanation of 
why this document ought to be a BCP. I encourage the document editors to 
continue that discussion. Important to the discussion is why you think 
it is necessary and justified that this document to be a BCP instead of 
an Informational RFC.

This document will at the very least be published as Informational. But 
I have put it back on the next IESG telechat to continue the 
conversation. On 14 July, we're going to make a call one way or the 
other. Please complete your discussion before then.


Pete Resnick<>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102