RE: I-D Action:draft-ietf-6man-exthdr-01.txt

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Wed, 05 January 2011 12:55 UTC

Return-Path: <manav.bhatia@alcatel-lucent.com>
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 CCEF83A6E1D for <ipv6@core3.amsl.com>; Wed, 5 Jan 2011 04:55:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.173
X-Spam-Level:
X-Spam-Status: No, score=-5.173 tagged_above=-999 required=5 tests=[AWL=1.426, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 3yKBUv0uKxGJ for <ipv6@core3.amsl.com>; Wed, 5 Jan 2011 04:55:01 -0800 (PST)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id F3A9E3A6B6B for <ipv6@ietf.org>; Wed, 5 Jan 2011 04:55:00 -0800 (PST)
Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p05Cv0S0008298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Jan 2011 06:57:04 -0600 (CST)
Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p05CuvRZ009568 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Jan 2011 18:26:58 +0530
Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 5 Jan 2011 18:26:57 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>
Date: Wed, 05 Jan 2011 18:26:56 +0530
Subject: RE: I-D Action:draft-ietf-6man-exthdr-01.txt
Thread-Topic: I-D Action:draft-ietf-6man-exthdr-01.txt
Thread-Index: Acus1mdij77lhbH7Rz2NYPnXm1yaAAAAXm2Q
Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFAF7FEF0@INBANSXCHMBSA1.in.alcatel-lucent.com>
References: <20101217234501.11691.81147.idtracker@localhost> <AANLkTi=Lr_4zOd=-DrAxic_t_o0MvyOoWPYmiktZZod2@mail.gmail.com> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <AA183326-2E70-4A23-83A7-9F96131ADFF4@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <4D2242E9.8040804@gont.com.ar> <201101041429.p04ET81p006364@cichlid.raleigh.ibm.com> <4D23563E.7000108@gont.com.ar> <4D235845.6040409@joelhalpern.com> <4FD1E7CD248BF84F86BD4814EDDDBCC150E9C64861@EUSAACMS0703.eamcs.ericsson.se> <4D2467B8.3090306@joelhalpern.com>
In-Reply-To: <4D2467B8.3090306@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
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: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Wed, 05 Jan 2011 12:55:01 -0000

 
> 
> For clarity, in terms of the pieces of your original note:
> 
> I consider (a), specifying the format at least to the level 
> of requiring 
> TLV encoding, to be a good idea.

I agree to this.

I think there is value in specifying a format that all subsequent extension headers MUST use.

Cheers, Manav

> 
> I do not see any particular advantage in (b), allocating a 
> code point, 
> but I can live with it if the WG wants it.
> 
> And (c), changing the RFC 2460 mandate on error and drop 
> handling, and 
> replacing it with the details used in destination option 
> bothers me.  It 
> seems to me we should have a strong reason for changing what 
> was agreed. 
>   Also, any usage of such bits will have to allow for existing 
> destinations, which will ignore such bits.  Still, if we want to make 
> using the extension headers easy, we should add the flag bits.  But I 
> don't know that we want to make it easy.  Just possible, if 
> we really, 
> badly, need to do it.
> 
> Yours,
> Joel
> 
> On 1/5/2011 5:25 AM, Suresh Krishnan wrote:
> ...
> > I would appreciate your response to
> >
> > http://www.ietf.org/mail-archive/web/ipv6/current/msg13207.html
> >
> > Thanks
> > Suresh
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>