Subject: [rrg] Next revision

From: Tony Li <[email-masked]>
Date: Thu, 21 Jan 2010 21:43:01 -0800

The next revision of the draft can be found here:

http://www.ietf.org/id/draft-irtf-rrg-recommendation-04.txt

Lixia will be making the next editing pass.

Tony

------------------------------
A new version of I-D, draft-irtf-rrg-recommendation-04.txt has been 
successfuly submitted by Tony Li and posted to the IETF repository.

Filename:	 draft-irtf-rrg-recommendation
Revision:	 04
Title:		 Recommendation for a Routing Architecture
Creation_date:	 2010-01-21
WG ID:		 Independent Submission
Number_of_pages: 51

Abstract:
It is commonly recognized that the Internet routing and addressing
architecture is facing challenges in scalability, multi-homing, and
inter-domain traffic engineering.  This document reports the Routing
Research Group's preliminary findings from its efforts towards
developing a recommendation for a scalable routing architecture.

This document is a work in progress.

The IETF Secretariat.

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Tue, 26 Jan 2010 15:56:46 -0600

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-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Li
Sent: Friday, January 22, 2010 12:43 AM
To: RRG
Subject: [rrg] Next revision

Tony

Abstract:

The IETF Secretariat.
_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.