Re: IAB last call... Re: [ipv6-dir] Re: Updated document

Brian E Carpenter <brc@zurich.ibm.com> Tue, 10 January 2006 14:06 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwK8s-0004Q0-Il; Tue, 10 Jan 2006 09:06:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwK8p-0004Pr-AT; Tue, 10 Jan 2006 09:06:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05020; Tue, 10 Jan 2006 09:05:06 -0500 (EST)
Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwKFX-0002Du-8P; Tue, 10 Jan 2006 09:13:24 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id k0AE0GXA075494; Tue, 10 Jan 2006 14:06:11 GMT
Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k0A9ej63085094; Tue, 10 Jan 2006 10:40:45 +0100
Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k0A9eiit023187; Tue, 10 Jan 2006 10:40:44 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k0A9ehBs023169; Tue, 10 Jan 2006 10:40:43 +0100
Received: from zurich.ibm.com (sig-9-145-252-37.de.ibm.com [9.145.252.37]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA45586; Tue, 10 Jan 2006 10:40:41 +0100
Message-ID: <43C38113.6010508@zurich.ibm.com>
Date: Tue, 10 Jan 2006 10:40:35 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
Subject: Re: IAB last call... Re: [ipv6-dir] Re: Updated document
References: <200601091455.k09Et2c2020603@cichlid.raleigh.ibm.com> <F5098923-4140-47F6-BEA1-DEB2CE368C0A@kurtis.pp.se>
In-Reply-To: <F5098923-4140-47F6-BEA1-DEB2CE368C0A@kurtis.pp.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate3.de.ibm.com id k0AE0GXA075494
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3
Content-Transfer-Encoding: quoted-printable
Cc: Thomas Narten <narten@us.ibm.com>, "<john.loughney@nokia.com> (Nokia-NRC/Helsinki) John" <john.loughney@nokia.com>, IAB IAB <iab@ietf.org>, Scott W Brim <sbrim@cisco.com>, Margaret Wasserman <MRW@devicescape.com>, Leslie Daigle <leslie@thinkingcat.com>, Bradner Scott <sob@harvard.edu>, ipv6-dir@ietf.org
X-BeenThere: ipv6-dir@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IPv6 Directorate <ipv6-dir.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6-dir>, <mailto:ipv6-dir-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6-dir@ietf.org>
List-Help: <mailto:ipv6-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6-dir>, <mailto:ipv6-dir-request@ietf.org?subject=subscribe>
Sender: ipv6-dir-bounces@ietf.org
Errors-To: ipv6-dir-bounces@ietf.org

I have no problems with this version. I don't understand the
mindset of the people asking the question well enough to judge
whether it's really on target. I wonder if we are missing some
general scene-setting at the beginning? Time is short to debate this,
but it's possible we should say something like

We remind the NGN community that IPv6 is a relatively conservative
replacement for IPv4, intentionally with no revolutionary features,
and that it is intended to overcome the addressing limitations and
some specific omissions in IPv4 without in any way fundamentally
changing the nature of the Internet. As such, we see very limited risk
and much to gain by unambiguous adoption of IPv6.

Or something.

   Brian

Kurt Erik Lindqvist wrote:
> 
> On 9 jan 2006, at 15.55, Thomas Narten wrote:
> 
>> Reading some of the comments, I sense there is still some discomfort
>> with the current version. Here's my attempt at slimming it down, i.e.,
>> having less "editorialization" and trying to simply point to WGs and
>> existing RFCs. The overall message should be: "there is lots of
>> ongoing work, talk to us about specifics". IMO, the less we say the
>> better, since we don't want any "advice" to be taken as some sort of
>> "recommendation". I'd want more details about a specific
>> question/usage before doing that. Best to just point to the existing
>> work and encourage them to come to the IETF with specific
>> questions. Saying more now is in some sense trying to anticipate their
>> questions, which we probably can't reasonably do.
> 
> 
> Me and Margaret chatted and I promised to do the edit. Which is  
> attached here. I _think_ that Thomas changes overlapped with Bob's  (but 
> I might have missed something) so I edited in Brians and Thomas  comments.
> 
> With two exceptions that I didn't know what to do with and I really  
> have a strong feeling one way or the other.
> 
>>> There is on-going work on IPv6 transition issues for SIP, see: ¡ÈIPv6
>>> Transition in the Session Initiation Protocol (SIP)¡É -
>>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-v6- 
>>> transition-01.txt.
>>
>>
>> moved to later in document...
> 
> 
> Where?
> 
>>> The IPv6 flow label identifier is a 20-bit field in the IPv6  header. A
>>> value of zero indicates that no flow id is set and no assumption on
>>> the packets being part of a flow can be made. Further, nodes must not
>>> assume that there is a semantic meaning of the flow label field. This
>>> has had relevance in several IETF Working groups and related work,
>>> where the possibility of using the Flow label field is considered for
>>> overloading the semantics for other work. This has most of the time
>>> been an artifact of work that would have benefited from a field of  its
>>> own in the IPv6 header. This has so far been deemed incompatible with
>>> the definition of the flow label field.
>>
>>
>> I'd suggest dropping the above, as it doesn't add anything beyond the
>> existing RFCs.
> 
> 
> This is now dropped. If Scott and Thomas agrees on what to do with it  I 
> am happy either way.
> 
>>
>>> Mobility.
>>>
>>> The IPv6 mobility model, Mobile Support in IPv6 aka Mobile IPv6, has
>>> been adopted from the IPv4 version Mobile IP, with some modifications
>>> and extensions.  Especially the security model for route optimisation
>>> is different.  Mobile IPv6 is documented in RFC 3775 and RFC 3776,
>>> with an optional extension in RFC 4283.  RFC 4225 explains the
>>> rational and design behind the route optimisation security model, and
>>> its limitations.
>>
>>
>> I'm not sure I understand why Mobility is being called out for
>> discussion. Is this a "NGN" topic? Mobility is _NOT_ what I normally
>> think of as "network infrastructure". Its largely an e2e approach
>> involving end nodes (mobile & correspondant nodes) and servers (Home
>> Agents). It is built on top of a network, it is not part of the "core"
>> network itself.  Also, there are a lot of IETF WGs that are doing IPv6
>> work that might be related. E.g., autoconf/manet. Do we mention them
>> all? What is the criteria for deciding  what to mention and what not?
>>
>> Also, the above isn't entirely accurate. For example, there is no
>> route optimization in MIPv4, so it doesn't make sense to say
>> "especially the security model for route optimization is different".
> 
> 
> I just answered the questions :-)
> 
> Could we get some input on this from Pekka that wrote the text? I  have 
> no feelings one wy ro the other. I didn't make any changes here.
> 
>>
>>> We are not aware of MPLS implementations for IPv6 networks, but will
>>> solicit this information and notify the ITU-T SG13 of the result when
>>> available.
>>
>>
>> Do we need the above? If so, shouldn't we say the same for other areas
>> (like mobility)? And has ITU-T specifically requested such
>> information? If not, why are we volunteering?
> 
> 
> Loa?
> 
> This text is also left as is...
> 
> - kurtis -


_______________________________________________
ipv6-dir mailing list
ipv6-dir@ietf.org
https://www1.ietf.org/mailman/listinfo/ipv6-dir