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
>