Re: [Rmt] AD comments on draft-ietf-rmt-pi-alc-revised-06

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 13 May 2009 09:41 UTC

Return-Path: <magnus.westerlund@ericsson.com>
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 CFA1E3A6AB3 for <rmt@core3.amsl.com>; Wed, 13 May 2009 02:41:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.211
X-Spam-Level:
X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 w-KNBJQIHFxD for <rmt@core3.amsl.com>; Wed, 13 May 2009 02:41:23 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8A6883A692C for <rmt@ietf.org>; Wed, 13 May 2009 02:41:21 -0700 (PDT)
X-AuditID: c1b4fb3e-b7bc1ae00000675c-b7-4a0a961bea9a
Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 1E.78.26460.B169A0A4; Wed, 13 May 2009 11:42:51 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 May 2009 11:41:21 +0200
Received: from [153.88.50.61] ([153.88.50.61]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 May 2009 11:41:21 +0200
Message-ID: <4A0A95C1.2000808@ericsson.com>
Date: Wed, 13 May 2009 11:41:21 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "Watson, Mark" <watson@qualcomm.com>
References: <C62F6020.2D01A%watson@qualcomm.com>
In-Reply-To: <C62F6020.2D01A%watson@qualcomm.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 13 May 2009 09:41:21.0697 (UTC) FILETIME=[F94AD110:01C9D3AE]
X-Brightmail-Tracker: AAAAAA==
Cc: "draft-ietf-rmt-pi-alc-revised@tools.ietf.org" <draft-ietf-rmt-pi-alc-revised@tools.ietf.org>, "rmt@ietf.org" <rmt@ietf.org>
Subject: Re: [Rmt] AD comments on draft-ietf-rmt-pi-alc-revised-06
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: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Wed, 13 May 2009 09:41:23 -0000

Hi Mark and the WG,

I think most proposed changes looks fine. I comment on the question
below. And we do need WG input into one question.

Watson, Mark skrev:
> On 4/17/09 7:08 AM, "Magnus Westerlund" <magnus.westerlund@ericsson.com>
> wrote:
> 
>> Hi,
>>
>> I have reviewed the ALC PI and have some comments.
>>
>> 1. If one compare this one with the experimental one they are very
>> similar. At least my expectation would be that a bit more details are
>> actually nailed down on how one should do them to achieve interoperable
>> implementations. For example the choice of congestion control algorithm.
>> I think we only have one that we can really use to satisfy the intended
>> usage of large scale sessions. Why isn't this a required to implement
>> feature?
>>
>> The same thing can be said about normative to implement security
>> features. Yes, here there are choices, but still specify one required to
>> implement should be possible. If you have observant the NORM PI got this
>> comment from the SECdir reviewer. And I think he was right, we should be
>> clear on these.
>>
>> A question is if we need to specify one mandatory to implement FEC
>> encoding?
>>
>> In general I am not against the flexibility the protocol allows for.
>> However, it should be clear what you do need to implement for a
>> base-line implementation.
>>
> 
> If I understand the WG discussion correctly, we should mandate the support
> of WEBRC for Congestion Control. I propose to replace the first sentence of
> section 2.2 (Multiple Rate Congestion Control Building Block) with
> 
> "At a minimum, implementations of ALC MUST support [RFC3738]."
> 
> And reword the following paragraphs appropriately.
> 
> For security, as with NORM, we have text defining 'Baseline secure ALC
> operation'. Do you think we should mandate support for this ?

Yes, I think so. But I definitely would like to get WG input into this
question.

>> 4. There are more references that are not updated. Cases where mechanism
>> are available in IETF draft, like the TESLA solution. Which would impact
>> the reference for example in Section 5, third paragraph.
>>
> 
> I added the TESLA for ALC/NORM draft as a reference and reference from that
> paragraph. Are there others that you saw other than those found by idnits ?

No, not what I can remember.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------