Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

JINMEI Tatuya / 神明達哉 <Jinmei_Tatuya@isc.org> Thu, 10 July 2008 05:15 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipv6-archive@megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239133A680E; Wed, 9 Jul 2008 22:15:00 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E473A63D2 for <ipv6@core3.amsl.com>; Wed, 9 Jul 2008 22:14:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.569
X-Spam-Level: *
X-Spam-Status: No, score=1.569 tagged_above=-999 required=5 tests=[AWL=-0.819, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLmQnKp6-Fwz for <ipv6@core3.amsl.com>; Wed, 9 Jul 2008 22:14:56 -0700 (PDT)
Received: from mon.jinmei.org (mon.jinmei.org [IPv6:2001:4f8:3:36::162]) by core3.amsl.com (Postfix) with ESMTP id EE1953A680E for <ipv6@ietf.org>; Wed, 9 Jul 2008 22:14:55 -0700 (PDT)
Received: from jmb.jinmei.org (user-64-9-237-16.googlewifi.com [64.9.237.16]) by mon.jinmei.org (Postfix) with ESMTP id 0BCA433C2E; Wed, 9 Jul 2008 22:15:02 -0700 (PDT)
Date: Wed, 09 Jul 2008 22:15:00 -0700
Message-ID: <m2mykq48x7.wl%Jinmei_Tatuya@isc.org>
From: JINMEI Tatuya / 神明達哉 <Jinmei_Tatuya@isc.org>
To: "Hemant Singh (shemant)" <shemant@cisco.com>
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
In-Reply-To: <B00EDD615E3C5344B0FFCBA910CF7E1D04E41F06@xmb-rtp-20e.amer.cisco.com> <B00EDD615E3C5344B0FFCBA910CF7E1D04E41F07@xmb-rtp-20e.amer.cisco.com>
References: <BB56240F3A190F469C52A57138047A03A9F348@xmb-rtp-211.amer.cisco.com> <m2r6a24lwi.wl%Jinmei_Tatuya@isc.org> <B00EDD615E3C5344B0FFCBA910CF7E1D04E41F06@xmb-rtp-20e.amer.cisco.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Cc: Thomas Narten <narten@us.ibm.com>, ipv6@ietf.org, Bob Hinden <bob.hinden@nokia.com>, Brian Haberman <brian@innovationslab.net>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

At Wed, 9 Jul 2008 20:54:04 -0400,
"Hemant Singh (shemant)" <shemant@cisco.com> wrote:

> Thanks for the reply. Let's see if we can meet common ground with you.
> 
> Our justification for prohibiting on-link caching is only in emails to
> 6man as follows:
> 
>  "What if there are cache-inconsistency problems, prefix renumbering, 
>  or stale information?  I think it's better just to get rid of 
>  caching on-link information in stable storage and get such 
>  information fresh from RA's.  That way, administrators can better 
>  rationalize the behavior of their network from the configured RA's." 

And I replied to this justification, saying this itself cannot justify
killing on-link caching while (perhaps implicitly) allowing address
caching.

> Also, when Suresh Krishnan pointed out that he supports bullet 3, he
> made us explicitly mention in the bullet that it's a new rule. We have
> been clear in the draft where there is a new rule and where it's
> clarification. Besides this new rule, the rest of the draft is
> clarification.

Suresh has his right to express his opinion, of course, and so do I.
I would not like this document to set new rules (note, again, that I'm
not objecting to discussing new changes to RFC4861/4862.  I'm simply
objecting to doing that in this document).

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------