Re: [rrg] Next revision

Tony Li <> Tue, 23 February 2010 06:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B07B3A843A for <>; Mon, 22 Feb 2010 22:11:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.979
X-Spam-Status: No, score=-9.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jOxjmKDt3lJj for <>; Mon, 22 Feb 2010 22:11:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 037873A67F9 for <>; Mon, 22 Feb 2010 22:10:59 -0800 (PST)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAE0Ag0urR7Hu/2dsb2JhbACbBnOicZg5hGkEgxU
X-IronPort-AV: E=Sophos;i="4.49,523,1262563200"; d="scan'208";a="241830442"
Received: from ([]) by with ESMTP; 23 Feb 2010 06:13:01 +0000
Received: from ( []) by (8.13.8/8.14.3) with ESMTP id o1N6D1s2001456; Tue, 23 Feb 2010 06:13:01 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 22:13:01 -0800
Received: from ([]) by ([]) via Exchange Front-End Server ([]) with Microsoft Exchange Server HTTP-DAV ; Tue, 23 Feb 2010 06:13:00 +0000
User-Agent: Microsoft-Entourage/
Date: Mon, 22 Feb 2010 22:12:58 -0800
From: Tony Li <>
To: "George, Wes E [NTK]" <>, Tony Li <>, RRG <>
Message-ID: <>
Thread-Topic: [rrg] Next revision
Thread-Index: Acq0Tz6mSDToPtosLESdnjuZTTGNTg==
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 23 Feb 2010 06:13:01.0211 (UTC) FILETIME=[409086B0:01CAB44F]
X-Mailman-Approved-At: Wed, 24 Feb 2010 13:02:44 -0800
Subject: Re: [rrg] Next revision
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Feb 2010 06:11:06 -0000

Hi Wes,

I agree with your sentiment here.  However, given the word count limits, and
the fact that it's going to be hard to tell what usage is first prior to us
having a full document, I suspect that an abbreviations section is highly
appropriate and the best approach.

Would folks care to contribute expansions, please?


On 1/26/10 1:56 PM, "George, Wes E [NTK]" <>

> In reading this draft as someone who has not been consistently on-list until
> very recently (December), and understanding that it is a work in progress, I
> have a comment for improved readability for the next pass revision:
> I would strongly recommend exploding any acronyms used in the summaries and
> critiques if they have not been defined previously in the document or section.
> It's currently quite inconsistent - I'm sure that this has a lot to do with
> the number of contributors, plus the ordering of the approaches within the
> draft. However, I get the impression that many authors, in an attempt to
> maximize the available word count, were a bit liberal in terms of what are
> "well-known" acronyms, but they may not all be so well-known to those not
> heavily involved in RRG or already familiar with the particular approach being
> discussed. [I|E|T]TR comes immediately to mind as something that is widely
> used but not defined until late in the draft if at all. ITR, not defined until
> section 8. ETR, not defined until section 13. TTR, not defined at all. PMTUD
> is defined in section 4, but DFZ is not defined when used just a few sentences
> prior. While not all of these examples are necessarily uncommon acronyms, I
> think it makes my point that this needs to be reviewed document-wide. It's
> probably easiest for the original contributor to make this review and provide
> updates as needed, but I'll leave that to the editors' discretion  :-)
> If this is an issue of word-count, this probably shouldn't count towards the
> limit, since it's largely for readability, but I do think that it needs to be
> done if the intent is to have these summaries be truly standalone - In other
> words, I will read the original draft if I need more detailed info about how
> an approach does something, but I shouldn't have to do it in order to get a
> basic sense of how it works because of acronym overload.
> Alternatively, a glossary section could be added, but I think that given the
> size of this draft, inline definitions would be easier for the reader than
> having to scroll to a different section each time they encounter an unknown
> acronym.
> Thanks,
> Wes George
> -----Original Message-----