Re: [Rmt] Last Call: draft-ietf-rmt-bb-norm-revised (MulticastNegative-Acknowledgment (NACK) Building Blocks) to Proposed Standard

Brian Adamson <adamson@itd.nrl.navy.mil> Fri, 18 July 2008 22:06 UTC

Return-Path: <rmt-bounces@ietf.org>
X-Original-To: rmt-archive@megatron.ietf.org
Delivered-To: ietfarch-rmt-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3924B3A68FB; Fri, 18 Jul 2008 15:06:17 -0700 (PDT)
X-Original-To: rmt@core3.amsl.com
Delivered-To: rmt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 938E33A68E3 for <rmt@core3.amsl.com>; Fri, 18 Jul 2008 15:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 m0b5byxe2U6N for <rmt@core3.amsl.com>; Fri, 18 Jul 2008 15:06:15 -0700 (PDT)
Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id 91DDC3A68FB for <rmt@ietf.org>; Fri, 18 Jul 2008 15:06:14 -0700 (PDT)
Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id m6ILCOct024967; Fri, 18 Jul 2008 17:12:24 -0400 (EDT)
Received: from macsimus.itd.nrl.navy.mil ([132.250.92.151]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2008071817122304497 ; Fri, 18 Jul 2008 17:12:23 -0400
Message-Id: <D43BA9CA-964B-446E-AC3D-F97A15DFFDC5@itd.nrl.navy.mil>
From: Brian Adamson <adamson@itd.nrl.navy.mil>
To: Pekka Savola <pekkas@netcore.fi>
In-Reply-To: <alpine.LRH.1.10.0804140835390.16919@netcore.fi>
Mime-Version: 1.0 (Apple Message framework v926)
Date: Fri, 18 Jul 2008 17:12:24 -0400
References: <20080403140021.9211F28C5C9@core3.amsl.com> <alpine.LRH.1.10.0804071058380.23953@netcore.fi> <p06240808c425883a5645@[132.250.92.151]> <alpine.LRH.1.10.0804140835390.16919@netcore.fi>
X-Mailer: Apple Mail (2.926)
Cc: Joe Macker <macker@itd.nrl.navy.mil>, rmt@ietf.org
Subject: Re: [Rmt] Last Call: draft-ietf-rmt-bb-norm-revised (MulticastNegative-Acknowledgment (NACK) Building Blocks) to Proposed Standard
X-BeenThere: rmt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Reliable Multicast Transport <rmt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rmt>
List-Post: <mailto:rmt@ietf.org>
List-Help: <mailto:rmt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: rmt-bounces@ietf.org
Errors-To: rmt-bounces@ietf.org

Hello Pekka,

The current posted version of the NORM BB draft has removed the  
discussion of intermediate system/ router assistance as you had  
suggested.  As you may have seen in another email, an IESG reviewer  
(Dave Ward) has requested:

"  a discussion about the applicability of network based NAK
	  implosion and/or local retransmitter based optimizations
	  to this building block, and whether or not it would be
	  possible to do this such that it can be added as an
	  afterthought into deployments without changes to senders
	  and/or receivers to better scale them upon increase of
	  topology and/or group-size. "


To satisfy this request, I am inclined to re-include some form of this  
discussion that was omitted in response to your comment.  BUT, I think  
it could be clarified that it would not necessarily be _router_  
assistance?  And to qualify the discussion more with respect to the  
pragmatics of deployment, etc ...  I think the discussion is merited  
since it will occur to people reading the document and the "NACK"  
building block is potentially _compatible_ with such mechanisms, but I  
agree with you that it is not sufficiently mature and the document  
should not explicitly _recommend_ anything here other than to discuss  
the associate points ...

What is your opinion on this?  I am updating the draft and I wanted to  
make sure we addressed your concerns if we adjusted the document to re- 
include some form of this discussion.

best regards,



Brian Adamson
adamson@itd.nrl.navy.mil




On Apr 14, 2008, at 2:35 AM, Pekka Savola wrote:

> Hi Brian,
>
> On Fri, 11 Apr 2008, Brian Adamson wrote:
>> I appreciate your comments here.  I plan to issue a new version of  
>> the draft
>> that addresses these to the extent I can.  I have some questions  
>> about your
>> concerns with comments in-line below:
>
> Thanks for your quick response.  Below I won't quote all the text if
> additional clarification doesn't seem warranted.
>
>> But this is certainly not a "fully-baked" area.  So [router
>> assistance] discussion _could_ be removed ... I suppose it will
>> persist in the RFC 3941 for historical purposes until there is
>> further interest in the area?
>
> That would be my preference.

_______________________________________________
Rmt mailing list
Rmt@ietf.org
https://www.ietf.org/mailman/listinfo/rmt