Re: [netext] Review of draft-ietf-netext-pmipv6-sipto-option-03

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Wed, 02 May 2012 12:57 UTC

Return-Path: <cjbc@it.uc3m.es>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF7A21F863D for <netext@ietfa.amsl.com>; Wed, 2 May 2012 05:57:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level:
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 3ta2UiWY32jI for <netext@ietfa.amsl.com>; Wed, 2 May 2012 05:57:55 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id BD30721F8639 for <netext@ietf.org>; Wed, 2 May 2012 05:57:54 -0700 (PDT)
X-uc3m-safe: yes
Received: from [192.168.1.3] (62.83.52.112.dyn.user.ono.com [62.83.52.112]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 05C7675AAF0; Wed, 2 May 2012 14:57:52 +0200 (CEST)
Message-ID: <1335963471.4285.21.camel@acorde.it.uc3m.es>
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: Sri Gundavelli <sgundave@cisco.com>
Date: Wed, 02 May 2012 14:57:51 +0200
In-Reply-To: <CBBDD33D.4402C%sgundave@cisco.com>
References: <CBBDD33D.4402C%sgundave@cisco.com>
Organization: Universidad Carlos III de Madrid
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-jOeLVLrpET5F9cPVByyo"
X-Mailer: Evolution 3.2.2-1
Mime-Version: 1.0
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18878.006
Cc: "netext@ietf.org" <netext@ietf.org>
Subject: Re: [netext] Review of draft-ietf-netext-pmipv6-sipto-option-03
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: cjbc@it.uc3m.es
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 May 2012 12:57:58 -0000

Sorry for the late reply. Thanks for the update. I don't have any
further comments.

Carlos

On Wed, 2012-04-25 at 16:13 -0700, Sri Gundavelli wrote:
> Hi Carlos, Yokota-san, Marco, Pierrick, Ahmad & folks ...
> 
> Thanks for all the review comments. Please let us know if there any comments
> missing.
> 
> http://tools.ietf.org/html/draft-ietf-netext-pmipv6-sipto-option-04
> 
> 
> Regards
> Sri
> 
> 
> 
> 
> On 2/5/12 11:58 PM, "Carlos Jesús Bernardos Cano" <cjbc@it.uc3m.es> wrote:
> 
> > Hi,
> > 
> > Some additional comments after a quick review of the draft:
> > 
> > - Section 3.1: I think there is a problem with the references, because
> > it appears in thge text: "If the received Proxy Binding Update includes
> > the IP Traffic Offload Selector option Section 4". I guess it should
> > say: "If the received Proxy Binding Update includes the IP Traffic
> > Offload Selector option (Section 4)". There are more instances referring
> > to other sections.
> > 
> > - Section 4. The IPTS options has the field "TS Format", which resembles
> > the option defined in RFC 6089 for the traffic selector sub-option, and
> > in this way re-uses the binary TS defined for IPv4 in RFC 6088. However,
> > the draft defines a new IANA space for this "TS Format" field, which
> > might be a bit confusing. Can we just re-use RFC 6089 space (now it only
> > has three values reserved: "0" that should not be used, and "1" for
> > binary TS IPv4, and "2" for binary TS IPv6)? I think we would avoid some
> > redundancy that might lead to confusion. If we do that, the draft would
> > probably need to define a flag or something to catch what it is now done
> > by putting a "TS Format" equal to "0".
> > 
> > - By doing offloading, there are issues associated to handovers (if the
> > mobile node moves, any traffic that was being offloaded would need to be
> > restarted). I guess some text on that would be helfpul.
> > 
> > Hope this helps,
> > 
> > Carlos
> 

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
   GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                IEEE Network Special Issue on
                  Video over Mobile Networks
 http://dl.comsoc.org/livepubs/ni/info/cfp/cfpnetwork0313.htm 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++