IETF Logo Mail Archive

Re: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC

Jouni Korhonen <jouni.nospam@gmail.com> Thu, 16 May 2013 07:35 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3976821F85D1 for <v6ops@ietfa.amsl.com>; Thu, 16 May 2013 00:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 tfMbf0PV4I-z for <v6ops@ietfa.amsl.com>; Thu, 16 May 2013 00:35:44 -0700 (PDT)
Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id EF12221F8F4A for <v6ops@ietf.org>; Thu, 16 May 2013 00:35:38 -0700 (PDT)
Received: by mail-ee0-f50.google.com with SMTP id c41so1607988eek.37 for <v6ops@ietf.org>; Thu, 16 May 2013 00:35:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=rCpr9pcJVo1XKB80yrEDkOt86/ZVbjloELEmsxNrTAk=; b=b88kVjT4Kton1k6pflk4FcUen5oQIl3fvjef40nQ3IvmThFGV/HRgRNt/5pVd/Y0hc Yelu20JoiUW0lWHeIbS4VSWLC0boRqpyUM0weKsxkReZn/Nsuy+kuZc9RqCMqhbFuZAr ZDsCoXu0bGM5CS0yYFrwUWNV6yP0bXWGE9URQ975DoMjbNwWi305q2z447w8xicGX1xL sYt8em/htTtsHjM0seYjFgT54DVzDed8cwV8QN8H+7kresrLzJfEjnmtBM4CTHYrRG2q CLBCEprTew4hTu21GiTmC0l7YhzAPLDJKTJtJIvnjMWbN5ktpNkS4HdZUbb3ejJ5CvrM VmEw==
X-Received: by 10.14.38.198 with SMTP id a46mr113519275eeb.11.1368689738099; Thu, 16 May 2013 00:35:38 -0700 (PDT)
Received: from ?IPv6:2001:1bc8:101:f101:853d:c84e:2840:1026? ([2001:1bc8:101:f101:853d:c84e:2840:1026]) by mx.google.com with ESMTPSA id q1sm8752752eez.6.2013.05.16.00.35.35 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 May 2013 00:35:36 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <FB14A1A3-586C-488E-91C9-89241704255D@delong.com>
Date: Thu, 16 May 2013 10:35:34 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <BF20A3F3-8B2B-4889-8D8C-A63B3945D7F5@gmail.com>
References: <8C48B86A895913448548E6D15DA7553B859B35@xmb-rcd-x09.cisco.com> <51916286.9070101@globis.net> <038302EE-DAE7-4722-B2A6-5F65F789F959@gmail.com> <5191DFC6.4050903@globis.net> <30285AC2-5365-4353-9465-5D42D5AFEA1F@gmail.com> <FB14A1A3-586C-488E-91C9-89241704255D@delong.com>
To: Owen DeLong <owen@delong.com>
X-Mailer: Apple Mail (2.1503)
Cc: Ray Hunter <v6ops@globis.net>, "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 May 2013 07:35:49 -0000

On May 15, 2013, at 8:13 PM, Owen DeLong <owen@delong.com> wrote:

>>> 
>>> What breaks if an end device supports receiving more than one PIO in an RA?
>> 
>> Probably nothing. There just are no gateways that would put more than one
>> PIO in an RA.
>> 
>> The language is there just because 3GPP specs are explicit on stating it 
>> as a restriction to SLAAC.
> 
> It's kind of a dumb restriction IMHO. I don't think it is valuable to bring dumb
> restrictions from 3GPP over to IETF unless it is necessary to avoid incompatibility.

I don't disagree about the "dumbness".. However, that is a restriction of the 
link itself and buried pretty deep in the architecture. So, if the UE receives
an RA with multiple PIOs a) someone is goofing around or b) the network side
is broken. In that regard, I would still like to keep some text around this
peculiarity in the document. Would it be acceptable to state the fact and say
something along the lines that changing the UE stack implementation to meet
this link requirement is not really needed?

- Jouni

v2.23.0 | Report a Bug | By Email