Re: [Gen-art] Gen-ART Last Call review of draft-ietf-avtcore-ecn-for-rtp-07.txt

Suresh Krishnan <suresh.krishnan@ericsson.com> Thu, 05 April 2012 15:19 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B3421F86D9 for <gen-art@ietfa.amsl.com>; Thu, 5 Apr 2012 08:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLscUmic7hQx for <gen-art@ietfa.amsl.com>; Thu, 5 Apr 2012 08:19:01 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 60B4C21F865D for <gen-art@ietf.org>; Thu, 5 Apr 2012 08:19:01 -0700 (PDT)
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q35FIpPS000809; Thu, 5 Apr 2012 10:19:00 -0500
Received: from [142.133.112.66] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 5 Apr 2012 11:18:50 -0400
Message-ID: <4F7DB7D9.8000904@ericsson.com>
Date: Thu, 5 Apr 2012 11:18:49 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <4F7798E9.2060806@ericsson.com> <4F796A9C.4000800@ericsson.com>
In-Reply-To: <4F796A9C.4000800@ericsson.com>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: General Area Review Team <gen-art@ietf.org>, "draft-ietf-avtcore-ecn-for-rtp.all@tools.ietf.org" <draft-ietf-avtcore-ecn-for-rtp.all@tools.ietf.org>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-avtcore-ecn-for-rtp-07.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2012 15:19:02 -0000

Hi Magnus,

On 04/02/2012 05:00 AM, Magnus Westerlund wrote:
> On 2012-04-01 01:53, Suresh Krishnan wrote:
>> I am the assigned Gen-ART reviewer for
>> draft-ietf-avtcore-ecn-for-rtp-07.txt
>>
>> For background on Gen-ART, please see the FAQ at
>> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
>>
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>>
>> Summary: This draft is ready for publication as Proposed Standard, but I
>> have a minor concern that you may like to address.
>>
>> Minor
>> =====
>>
>> * The document uses some addresses in the RFC1918 range as example
>> addresses. It would be better to use addresses explicitly reserved for
>> documentation (The document does indeed use these addresses as well).
>> Specifically I would recommend replacing the RFC1918 address 10.0.1.4
>> with an address in the 203.0.113.0/24 range from RFC5735.
>>
> 
> Thanks for the review.
> 
> I am very well aware of that I am using an none documentation range. The
> point of the example is that it is an ICE and ECN SDP signalling
> example. When using ICE (RFC5245) it is likely that an end-point will
> have an private range address, either in the 10.0.0.0/8 or
> 192.168.0.0/16 address in their candidate lists. Thus to keep the
> example correct considering that the SDP represents a client attached to
> a NATed network and have multiple candidates I do need to use a private
> range address in this example or it would not make sense.

That makes sense. Too bad there is no documentation addresses set aside
for denoting private space.

Cheers
Suresh