[multrans] Comments on draft-jaclee-behave-v4v6-mcast-ps-01

Tom Taylor <tom111.taylor@bell.net> Sat, 09 April 2011 17:41 UTC

Return-Path: <tom111.taylor@bell.net>
X-Original-To: multrans@core3.amsl.com
Delivered-To: multrans@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89F543A6889 for <multrans@core3.amsl.com>; Sat, 9 Apr 2011 10:41:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.259
X-Spam-Level:
X-Spam-Status: No, score=-101.259 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuQG3+ZBPVQe for <multrans@core3.amsl.com>; Sat, 9 Apr 2011 10:41:49 -0700 (PDT)
Received: from blu0-omc4-s8.blu0.hotmail.com (blu0-omc4-s8.blu0.hotmail.com [65.55.111.147]) by core3.amsl.com (Postfix) with ESMTP id C82CA3A6819 for <multrans@ietf.org>; Sat, 9 Apr 2011 10:41:46 -0700 (PDT)
Received: from BLU0-SMTP97 ([65.55.111.137]) by blu0-omc4-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 9 Apr 2011 10:43:32 -0700
X-Originating-IP: [64.231.151.226]
X-Originating-Email: [tom111.taylor@bell.net]
Message-ID: <BLU0-SMTP97181E75A0A8DF299F2A72D8A60@phx.gbl>
Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP97.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 9 Apr 2011 10:43:32 -0700
Date: Sat, 9 Apr 2011 13:43:33 -0400
From: Tom Taylor <tom111.taylor@bell.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: multrans@ietf.org
References: <C9C09A56.C22E%yiu_lee@cable.comcast.com>
In-Reply-To: <C9C09A56.C22E%yiu_lee@cable.comcast.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Apr 2011 17:43:32.0711 (UTC) FILETIME=[A5073770:01CBF6DD]
Subject: [multrans] Comments on draft-jaclee-behave-v4v6-mcast-ps-01
X-BeenThere: multrans@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discuss the work of IPv4-IPv6 multicast." <multrans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/multrans>, <mailto:multrans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multrans>
List-Post: <mailto:multrans@ietf.org>
List-Help: <mailto:multrans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multrans>, <mailto:multrans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2011 17:41:50 -0000

I'll mention that I have many purely editorial comments at the micro 
level (e.g., better ways to say some things in English, spelling out of 
acronyms and abbreviations on first use). Christian, you can advise me 
on the form in which you want to see this: as an XML file, by marked-up 
text, or whatever.

My primary concern is that the current organization lacks focus because 
it considers the delivery infrastructures without separating the 
concerns posed by source and group address acquisition, interworking and 
forwarding of control messages, and distribution of content. In 
addition, requirements seem to be scattered through the document rather 
than grouped in one place.

Just looking at the table of contents, I have these proposals:

a) Instead of 2. Discussion, you should have 2. Service Requirements. 
This is the part the operator owns.

b) 4.1 Fast Zapping, 4.5 SLA Considerations, 4.6 Load Balancing, and 4.7 
Bandwidth Consumption should all be moved into the Service Requirements 
section. If there is material there that belongs in later sections it 
can be extracted and moved.

c) Section 4 should be organized into three subsections:
    -- Group and Source Discovery Considerations
    -- Control Signalling and Multicast Tree Computation
    -- Content Distribution
The benefit of doing this is that features common to the various use 
cases may emerge where they do not at present because grouping 
everything together makes every case seem to be unique.

d) Within these subsections, the implications of the different use cases 
should be explored. That probably means grabbing some of the content 
from Section 3.

Tom