Re: Stephen Farrell's No Objection on draft-ietf-6man-ext-transmit-04: (with COMMENT)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 11 October 2013 12:13 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C8821E80FE; Fri, 11 Oct 2013 05:13:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.549
X-Spam-Level:
X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glAzC7-ZU2JW; Fri, 11 Oct 2013 05:13:42 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 97DB221E80FB; Fri, 11 Oct 2013 05:13:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DC97EBE50; Fri, 11 Oct 2013 13:13:38 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0I9lEFx71U9j; Fri, 11 Oct 2013 13:13:38 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 899DCBE4D; Fri, 11 Oct 2013 13:13:38 +0100 (IST)
Message-ID: <5257EB74.9070309@cs.tcd.ie>
Date: Fri, 11 Oct 2013 13:13:40 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: Stephen Farrell's No Objection on draft-ietf-6man-ext-transmit-04: (with COMMENT)
References: <20131008103111.25649.95882.idtracker@ietfa.amsl.com> <52577D97.1010009@gmail.com>
In-Reply-To: <52577D97.1010009@gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-ext-transmit@tools.ietf.org, ipv6@ietf.org, The IESG <iesg@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 11 Oct 2013 12:13:48 -0000

On 10/11/2013 05:24 AM, Brian E Carpenter wrote:
> On 08/10/2013 23:31, Stephen Farrell wrote:
> ...
>> - 2.1 says nodes SHOULD forward rfc4727 experimental
>> headers, but earlier said that its ok (nodes MAY) default
>> to not forwarding packets with experimental headers. I
>> think you need to add an "unless otherwise stated here"
>> to the statement about defaults for experimental headers.
> 
> I must be missing something, but I can't find an inconsistency.

Or maybe I misread it.

I read it as saying "nodes MAY default to not forwarding
packets with experimental headers" and as also saying
"nodes SHOULD forward 4727 experimental headers."

My suggestion is to say "nodes MAY default to not forwarding
packets with experimental headers except as noted below"
since otherwise developers might just see the MAY and
ignore the SHOULD.

That's not quite fixing an inconsistency but more just
flagging that there's a SHOULD later for 4727. But if you
prefer it as-is that's fine.

Cheers,
S

> 
>>
>> - section 4: Is it wise to ask IANA to "redirect" users
>> from one (empty) registry to another? That could be the
>> start of a slippery slope turning IANA registries into a
>> miasma of hypertext;-) Maybe it'd be better to ask that
>> IANA mark that registry as having being replaced by this
>> new one. Also - what if someone else asks IANA to add an
>> entry to the currently empty registry but not the new one
>> - is it clear what should happen in that case?
> 
> It does need to be clear that the old registry is closed,
> but we have to leave a pointer because it's referred to
> elsewhere. I think IANA can figure it out, but we should
> add "close to new entries".
> 
> I think we are already in a miasma of hypertext.
> 
>      Brian
>>
>>
>>