IETF Logo Mail Archive

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

Jouni Korhonen <jouni.nospam@gmail.com> Fri, 17 May 2013 10:40 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 86FBE21F91A3 for <v6ops@ietfa.amsl.com>; Fri, 17 May 2013 03:40:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.549
X-Spam-Level:
X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 blHckRPQDnl6 for <v6ops@ietfa.amsl.com>; Fri, 17 May 2013 03:40:23 -0700 (PDT)
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6026021F9412 for <v6ops@ietf.org>; Fri, 17 May 2013 03:40:23 -0700 (PDT)
Received: by mail-lb0-f179.google.com with SMTP id r11so147284lbv.38 for <v6ops@ietf.org>; Fri, 17 May 2013 03:40:22 -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=cl1E5RCLuXuRJezjbKCaOQ6WDrwGeENhTi3BGHuTGac=; b=kbU4CXDF4ydnDmVIWDZqIeaYtf7LxITrReBUvu8uSqCT4ZsRoJ1iO3HtKmzj+4zMdD I/kaXDcZgPRzbUbw3f5sbRbxGzaEn79+3YMqQSUBy+g9C1aXBSM8UbqbwWF0ybYyPLhZ j7s0u5SAxFut7e/hqAtqmQ+Yk2Xoi792CbyOzV9wBM83ww5o9v6ZWcyujixEjmCeQe4V ueR6jCmsXO8+SC+9YyjT4ssKpK6KHbub0uDDhbIAuN4mjfQW/d8azSRNr1OHIN+E3ti0 hWM++8yHmYX8IPYbC4xacIrAMO8274k3DTI/9TXhbyEy9TBxuDyLrpqBz4i3ySEgAmiC MKKQ==
X-Received: by 10.112.73.135 with SMTP id l7mr22046911lbv.42.1368787222139; Fri, 17 May 2013 03:40:22 -0700 (PDT)
Received: from [192.168.250.206] ([194.100.71.98]) by mx.google.com with ESMTPSA id w3sm4661506lae.7.2013.05.17.03.40.18 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 May 2013 03:40:19 -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: <8C48B86A895913448548E6D15DA7553B8EA56B@xmb-rcd-x09.cisco.com>
Date: Fri, 17 May 2013 13:40:16 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <9259FD6E-503B-4146-8376-8DDF2DBB9841@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> <BF20A3F3-8B2B-4889-8D8C-A63B3945D7F5@gmail.com> <8C48B86A895913448548E6D15DA7553B8EA56B@xmb-rcd-x09.cisco.com>
To: "Fred Baker (fred)" <fred@cisco.com>, "v6ops@ietf.org Operations" <v6ops@ietf.org>
X-Mailer: Apple Mail (2.1503)
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: Fri, 17 May 2013 10:40:28 -0000

Btw.. The upcoming draft version -03 and its changes can be tracked 
in Github: https://github.com/jounikor/draft-ietf-v6ops-rfc3316bis

- Jouni


On May 16, 2013, at 10:08 PM, Fred Baker (fred) <fred@cisco.com> wrote:

> 
> On May 16, 2013, at 12:35 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:
> 
>> 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?
> 
> </chair>
> From my perspective, it sounds like a good idea. Making the UE accept multiple prefixes even if they will not be sent is simply robust software design. Imagine that someone sent a n RA with two PIOs (pick your reason that might happen - maybe it's a trial or something). Making a software change on the UE that caused it to not understand the information element could cause one of several kinds of failure. I'd suggest that the document recommend that the UE be robust to the potential event.

v2.23.0 | Report a Bug | By Email