Re: [netext] Stephen Farrell's No Objection on draft-ietf-netext-pmipv6-flowmob-17: (with COMMENT)

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Thu, 17 March 2016 12:54 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 E35C812DBDF for <netext@ietfa.amsl.com>; Thu, 17 Mar 2016 05:54:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgluB-uLaBDh for <netext@ietfa.amsl.com>; Thu, 17 Mar 2016 05:54:30 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C20A12DBF7 for <netext@ietf.org>; Thu, 17 Mar 2016 05:53:27 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id l68so115766329wml.1 for <netext@ietf.org>; Thu, 17 Mar 2016 05:53:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=QybZfRNuMCGRgwpDkpmpJsR8Z3bESRVUz++3KhZVY9w=; b=FBtmp7g/6EMZMq4ewph7h+ACNpkkX9FxBohBn/mS7eGkxggXn7Jw1FbBIySS++7zrq iYbiYJ6uBRC1JcYgXKvb1pPx/wygM7KvDn+89Lpw7r61iaCFfuYXeRMe30LI7GEFTZri CchUfK75mdswtlDs3Fgde5tIbSdZSLB86Q1DtP061mYkjJoNrWvQ8N8bWu+r53MqiEx/ zT5M8z1hNtAStk0KHtynu5kFiZz4qVIhOTWk0hI0BFicUE4w7IkaAS2tjIyy13G4gMu4 rnAIeUhas1f1MtsWUnDWaiTCzqdY3W1XlGh6IAD+VJGsmVf2MiAbEyth52jN/y7u/oyd FpLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=QybZfRNuMCGRgwpDkpmpJsR8Z3bESRVUz++3KhZVY9w=; b=DKYkprAbo2qnxQK/mCa1evVZU6JQOno1ftwDibB4yzugNxErymbQe+ZaG6YHWQ98ms 7Fjo82mDdAg51OLBy4F8PNsesF5qNvvlJKFmAaFBRzdxaoYXUrQ4S2UJ8oXNOTFq8uy3 H6rqipWfhtrsZ20bKXSe6lTdI9YYY5JH/4PRD5YjiicYC2EcpP1BMLIP2rwKDjazGOyQ /r0QW3QG2ATr9dY0G600tBwx8T+9tDk0UJ5lmXUGED91KNiY2p85uhZLP/Amu0igFRMT T+3VmIzwhFMTWDnTJhiNl9b/95PJmLuLuQGoY5t60CCnlVEd5Ala8/j4rHUXtpufDjj+ kO8Q==
X-Gm-Message-State: AD7BkJK+jmQbbF56j9yLXfpHhmkQySci52pJsxfFzmS+u/0td6+bFq8EzoAFUel1KXi0GmHF
X-Received: by 10.194.114.166 with SMTP id jh6mr9809971wjb.39.1458219205991; Thu, 17 Mar 2016 05:53:25 -0700 (PDT)
Received: from cjbc_dell.lan (82.158.203.25.dyn.user.ono.com. [82.158.203.25]) by smtp.gmail.com with ESMTPSA id j18sm30246148wmd.2.2016.03.17.05.53.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2016 05:53:25 -0700 (PDT)
Message-ID: <1458219204.3682.59.camel@it.uc3m.es>
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
Date: Thu, 17 Mar 2016 13:53:24 +0100
In-Reply-To: <20160317113037.10560.4562.idtracker@ietfa.amsl.com>
References: <20160317113037.10560.4562.idtracker@ietfa.amsl.com>
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.18.3-1
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/netext/S0ChGCL3iZEV9PNlP99DVb7JPUU>
Cc: netext@ietf.org, netext-chairs@ietf.org, draft-ietf-netext-pmipv6-flowmob@ietf.org
Subject: Re: [netext] Stephen Farrell's No Objection on draft-ietf-netext-pmipv6-flowmob-17: (with COMMENT)
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 17 Mar 2016 12:54:32 -0000

Hi Stephen,

On your comment, I must say that I have a different opinion from what
is expressed in the shepherd write-up :D. I think there is a demand for
flow mobility. Just to cite an example, the document is referenced
in 3GPP TR 23.861 (Network based IP flow mobility).

Thanks,

Carlos

On Thu, 2016-03-17 at 04:30 -0700, Stephen Farrell wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-netext-pmipv6-flowmob-17: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut
> this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.
> html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netext-pmipv6-flowmob/
> 
> 
> 
> -------------------------------------------------------------------
> ---
> COMMENT:
> -------------------------------------------------------------------
> ---
> 
> The shepherd write-up says: 
> 
>   "Have a significant number of vendors indicated their plan to
>   implement the specification? 
> 
>   No. The relevance of flow mobility at the present time is
>   suspect. While there is some adoption of Proxy Mobile IPv6 by
>   the industry, there is no real demand for flow based mobility."
> 
> I wondered why this is then being frozen into an RFC? That can
> be the right thing to do sometimes, but the above does make it
> seem questionable. So I'm asking:-) And did you consider if an
> experimental RFC would send the right signal?
> 
>