Re: Last Call: draft-manner-router-alert-iana (IANA Considerations for the IPv4 and IPv6 Router Alert Option) to Proposed Standard
Robert Elz <kre@munnari.OZ.AU> Thu, 10 July 2008 16:10 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F20D3A6A10; Thu, 10 Jul 2008 09:10:09 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 927373A69D4 for <ietf@core3.amsl.com>; Thu, 10 Jul 2008 09:10:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.048
X-Spam-Level:
X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=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 JkQUdnJx4GCH for <ietf@core3.amsl.com>; Thu, 10 Jul 2008 09:10:05 -0700 (PDT)
Received: from jade.coe.psu.ac.th (unknown [202.28.99.196]) by core3.amsl.com (Postfix) with ESMTP id D431D3A6891 for <ietf@ietf.org>; Thu, 10 Jul 2008 09:10:04 -0700 (PDT)
Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m6AG92HC003387 for <ietf@ietf.org>; Thu, 10 Jul 2008 23:09:02 +0700 (ICT)
Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by epsilon.noi.kre.to (8.14.2/8.14.2) with ESMTP id m6AG8CGX005665 for <ietf@ietf.org>; Thu, 10 Jul 2008 23:08:12 +0700 (ICT)
From: Robert Elz <kre@munnari.OZ.AU>
To: ietf@ietf.org
Subject: Re: Last Call: draft-manner-router-alert-iana (IANA Considerations for the IPv4 and IPv6 Router Alert Option) to Proposed Standard
In-Reply-To: <20080709164103.7733D28C1AF@core3.amsl.com>
References: <20080709164103.7733D28C1AF@core3.amsl.com>
Mime-Version: 1.0
Date: Thu, 10 Jul 2008 23:08:12 +0700
Message-ID: <16793.1215706092@epsilon.noi.kre.to>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
Date: Wed, 9 Jul 2008 09:41:03 -0700 (PDT) From: The IESG <iesg-secretary@ietf.org> Message-ID: <20080709164103.7733D28C1AF@core3.amsl.com> | The IESG has received a request from an individual submitter to consider | the following document: | | - 'IANA Considerations for the IPv4 and IPv6 Router Alert Option ' | <draft-manner-router-alert-iana-03.txt> as a Proposed Standard Two comments. First (last sentence of section 2): It is unclear why nesting levels begin at 1 for IPv4 (described in section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in section 6 of [RFC3175]). isn't the kind of sentence that belongs in a doc like this. If the authors are mystified, just omit the sentence, including it adds nothing. Better, of course, would be to ask, and discover, and provide an explanation. But, this doc deletes aggregation level 0 from IPv6 anyway, which makes all of this even stranger. Second (section 4, security considerations): Yet, as discussed in RFC 4727 [RFC4727] production networks do not necessarily support the use of experimental code points in IP option headers. The network scope of support for experimental values should carefully be evaluated before deploying any experimental RAO value [...] This is the kind of thing we might have expected to see in a security considerations section 15-20 years ago, when the network was a nice kind friendly environment, where all the players would take great care not to do anything that might cause a problem. These days, if "the use of unsupported experimental code points" has the "potential to disrupt the stable operation of the network" then that would be something worthy of a CERT advisory and hasty code fixes by whatever vendors are supplying the systems that would be disrupted. It is never safe to assume that any random value won't appear in any random field of a packet, and for just the same reason, there's no reason for anyone to avoid using any particular value. This security consideration paragraph should simply be deleted. The following one is more just common sense, wrt general management, and also exposes no security issues, and should probably be deleted as well. All of this (except the first paragraph which is fine) smells very much like an attempt to provide some meaningful security considerations section just because meaningful security considerations sections are required (by someone, for something) even where it's absurd to imagine any security issues that can really apply. If real security considerations were to be discussed in a doc that just establishes an IANA registry, and does no more than that (doesn't create new values with meanings that didn't already exist, etc) then about all that could be really said would be abut spoofing messages to IANA causing bogus values to be allocated, and/or adequately protecting the registry content so it is known that what is observed there is in fact correct - but none of that is really worth having in every RFC that happens to create a new IANA object. Personally I'd prefer to simply see the meaningless security considerations section removed completely from this doc (but of course, there's a "rule" that says it must always be present, even when it is stupid, and obeying the rules is, of course, far more important than producing quality documents...) kre _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Re: Last Call: draft-manner-router-alert-iana (IA… Robert Elz
- Re: Last Call: draft-manner-router-alert-iana (IA… Joe Baptista
- Re: Last Call: draft-manner-router-alert-iana (IA… Jari Arkko
- Re: Last Call: draft-manner-router-alert-iana (IA… Jukka MJ Manner
- Re: Last Call: draft-manner-router-alert-iana (IA… Jari Arkko
- Re: Last Call: draft-manner-router-alert-iana (IA… Jukka MJ Manner