Re: [v6ops] Planning for IETF #90
"Fred Baker (fred)" <fred@cisco.com> Thu, 03 July 2014 14:21 UTC
Return-Path: <fred@cisco.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6D51B2A6E for <v6ops@ietfa.amsl.com>; Thu, 3 Jul 2014 07:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -115.152
X-Spam-Level:
X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
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 ggI4g5N94kE4 for <v6ops@ietfa.amsl.com>; Thu, 3 Jul 2014 07:21:34 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0C21B2A0E for <v6ops@ietf.org>; Thu, 3 Jul 2014 07:21:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6274; q=dns/txt; s=iport; t=1404397294; x=1405606894; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0ztR5RqbHLA0scgTItvrnbnUOlsjnbE2ZdIajfmpUsA=; b=ahSVdlN5HoElC5P2QEQDZnauCcnl5+gRgBrAa2rJRzMwTAQidKK1PkEx R7lCwCs4VPZc7IhlyfBRPcx0R2eDtxe2ilN4/+BzmfFdhFeyxer+4W5jW Z2p/AyLJ925xozUcM9YFF1lLhXEEP7jRhaLgoiNVg03mkjhqNkOXFK5mc w=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjAFAONltVOtJA2G/2dsb2JhbABagw1SWoJvwy4BgQYWdYQDAQEBBCEBQwgMDAQCAQgRBAEBAQ8YAgMCMhQJCAIEDgUOiDQNkH2cIgGbcxeOQBACAU8HBoJuOYEWBZIcgUOCdoQYgUiSQoNDbIFE
X-IronPort-AV: E=Sophos;i="5.01,595,1400025600"; d="asc'?scan'208";a="58069162"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP; 03 Jul 2014 14:21:33 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s63ELXTj018560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jul 2014 14:21:33 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 09:21:33 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: V6 Ops List <v6ops@ietf.org>
Thread-Topic: Planning for IETF #90
Thread-Index: AQHPdSzfBnWUD3cMwE+7V8ANe7NhvJuORuGQgAC2woA=
Date: Thu, 03 Jul 2014 14:21:32 +0000
Message-ID: <504ED52D-B94C-4758-AE07-17789EF4FD2E@cisco.com>
References: <43AE4B9F-206F-4969-81B8-AE003DC9DF4C@cisco.com> <8392F9BAC6AD5F47920216A6D7853F7E1D62B8CF@BPXM02GP.gisp.nec.co.jp>
In-Reply-To: <8392F9BAC6AD5F47920216A6D7853F7E1D62B8CF@BPXM02GP.gisp.nec.co.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.113.202]
Content-Type: multipart/signed; boundary="Apple-Mail=_D032D6E9-AE9F-4618-ABCF-A3965B3B35F1"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/SyahoPpsOcmb8cxUpzztD1GA8XE
Cc: "Ata, Shingo (ata@info.eng.osaka-cu.ac.jp)" <ata@info.eng.osaka-cu.ac.jp>
Subject: Re: [v6ops] Planning for IETF #90
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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, 03 Jul 2014 14:21:37 -0000
v6ops: Kitamura-san has posted draft-kitamura-ipv6-zoneid-free, and would like operational views on it. He has also requested agenda time at IETF 90. I suspect it may be more suited for 6man, but 6man isn’t meeting. Would you kindly take a look and comment? If there is operational interest, we can give him a slot. Fred On Jul 3, 2014, at 1:47 AM, Hiroshi Kitamura <kitamura@da.jp.nec.com> wrote: > Dear co-chairs of v6ops WG, > > We have submitted a I-D: > "Free from Using Zone Identifier for IPv6 Link-Local Address" > <draft-kitamura-ipv6-zoneid-free-03.txt> > > I quote the I-D Announce mail at the end of this mail. > > This idea "Zone-ID Free" is simple and harmless to the current system. > We think this idea helps many people who face problems on Zone-ID. > > So, could you give us a presentation time at 90th Toronto meeting, please? > > > - title and file name of the draft > > "Free from Using Zone Identifier for IPv6 Link-Local Address" > <draft-kitamura-ipv6-zoneid-free-03.txt> > > - speakers name and email > > Hiroshi KITAMURA > kitamura@da.jp.nec.com > > - how much time > > 10 min. > > Best Regards, > Hiroshi > > >> -----Original Message----- >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >> Sent: Wednesday, July 02, 2014 12:17 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-kitamura-ipv6-zoneid-free-03.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : Free from Using Zone Identifier for IPv6 Link-Local Address >> Authors : Hiroshi Kitamura >> Shingo Ata >> Masayuki Murata >> Filename : draft-kitamura-ipv6-zoneid-free-03.txt >> Pages : 17 >> Date : 2014-07-01 >> >> Abstract: >> This document describes "Zone-ID Free" functions that make end >> users free from using zone identifiers (Zone-ID) for IPv6 link- >> local addresses. >> >> When users deal with IPv6 link-local addresses, it is thought that >> it is mandatory thing to specify accompanied Zone-IDs. For end >> users, however, it is troublesome and nuisance thing to do it. >> Because it is very hard for normal end users to find appropriate >> Zone-IDs for this purpose. >> >> From another viewpoint, the usage of IPv6 link-local addresses >> accompanied with Zone-IDs is quite different from the traditional >> usage of global addresses. Therefore many problems related with >> Zone-ID are caused and new specifications are required to fix these >> problems. >> >> This document explores and describes how "Zone-ID Free" functions >> work and how end users are released from using Zone-IDs when they >> deal with IPv6 link-local addresses. >> >> The "Zone-ID Free" functions are upper compatible with the current >> usages of dealing with IPv6 link-local addresses and harmless to >> the existing communications. >> >> In order to obtain appropriate Zone-ID information, a new >> technology "Zone-ID Learning" that issues multiple probes is >> introduced. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-kitamura-ipv6-zoneid-free/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-kitamura-ipv6-zoneid-free-03 > > > > > > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) >> Sent: Thursday, May 22, 2014 4:43 AM >> To: v6ops >> Subject: [v6ops] Planning for IETF #90 >> >> IETF #90 is two months away, and we have about six weeks to get drafts updated or new drafts filed. This is a heads-up. >> My rule for putting drafts on the agenda is that they are file or updated since the last IETF meeting and have had supportive >> working group commentary on the list. Filing at the last instant generally doesn’t help with folks’ commentary - you want >> to give them some time to read and think. So, filing drafts or making updates in June is recommended. >> >> Current draft status: >> >> IESG: >> Jan 12 draft-ietf-v6ops-enterprise-incremental-ipv6 >> Mar 10 draft-ietf-v6ops-nat64-experience >> Apr 1 draft-ietf-v6ops-64share >> >> Exiting WGLC; on its way to IESG: >> May 19 draft-ietf-v6ops-clatip >> >> Working Group Document updated since IETF: >> Mar 6 draft-ietf-v6ops-design-choices >> Mar 11 draft-ietf-v6ops-mobile-device-profile >> >> Individual Submission updated since IETF: >> Mar 4 draft-cui-v6ops-lte-lw4over6 >> Apr 7 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node >> >> Working Group Document NOT updated since IETF: >> Nov 26 draft-ietf-v6ops-dhcpv6-slaac-problem >> Dec 6 draft-ietf-v6ops-balanced-ipv6-security >> Jan 13 draft-ietf-v6ops-ipv6-roaming-analysis >> Feb 4 draft-ietf-v6ops-dc-ipv6 >> Feb 14 draft-ietf-v6ops-ula-usage-recommendations >> >> Individual Submission NOT updated since IETF: >> Dec 3 draft-taylor-v6ops-fragdrop >> Jan 11 draft-osamu-v6ops-ipv4-literal-in-url >> Feb 13 draft-cui-v6ops-lte-lw4over6 >> Feb 14 draft-foo-v6ops-6rdmtu >> Feb 14 draft-liu-v6ops-dhcpv6-slaac-guidance >
- [v6ops] Planning for IETF #90 Fred Baker (fred)
- Re: [v6ops] Planning for IETF #90 Fred Baker (fred)
- Re: [v6ops] Planning for IETF #90 神明達哉
- Re: [v6ops] Planning for IETF #90 Ray Hunter
- Re: [v6ops] Planning for IETF #90 Alejandro Acosta