[OSPF] Stephen Farrell's No Objection on draft-ietf-ospf-te-metric-extensions-09: (with COMMENT)
"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Sun, 04 January 2015 02:07 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1DD1A1AD8; Sat, 3 Jan 2015 18:07:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 aOOXj2_aT8ZZ; Sat, 3 Jan 2015 18:07:19 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B191A1ACA; Sat, 3 Jan 2015 18:07:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150104020718.29256.7059.idtracker@ietfa.amsl.com>
Date: Sat, 03 Jan 2015 18:07:18 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/EqQ2NzPaIeIadfcsGedr_TvEyho
Cc: ospf@ietf.org, ospf-chairs@tools.ietf.org, draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org
Subject: [OSPF] Stephen Farrell's No Objection on draft-ietf-ospf-te-metric-extensions-09: (with COMMENT)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Jan 2015 02:07:23 -0000
Stephen Farrell has entered the following ballot position for draft-ietf-ospf-te-metric-extensions-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- These are mainly nits or questions, other than the first. That would have been a discuss if I knew of a specific threat, but since this is just a general concern, it's not a discuss. I'd appreciate a bit of a chat about it though. - I'd have thought that these TLVs would be sent more often than others, and that (if enormous amounts of money are in play) then use of OSPF authentication might be more likely needed (or some equivalent security mechanisms). I'd even speculate that if enormous amounts of money are in play, then confidentiality may become a requirement (since if I can observe say A bit settings then that might give me insight into traffic levels - sort of a lights burning at night in central bank implies interest-rate change attack). Can you say why none of that needs to be mentioned at all? Was any of that considered by the WG? (Can you send a relevant link to the archive?) - intro: "extremely large amounts of money" aren't usually explicit motivations for protocol features and I hope that that continues to be the case. I'd encourage you to remove that phrase. Similarly, "faster" is a fine requirement but "fast than the competition" is not, so a bit more wordsmithing might be good. (Those are, I think, defensible points as we ought not over-specialise our requirements, but to be honest I'd also be happier if protocol development was not explicitly motivated soley by increasing already-enormous amounts of money.) - intro: saying the "measurement of delay SHOULD NOT vary significantly based upon the offered traffic load" is odd. Clearly the delay experienced can vary based on the load, so I'm not sure what you're saying. And nor is it clear why this is a SHOULD NOT, as opposed to a MUST NOT. Maybe you need to explain that some more? - section 3: Doesn't the A bit definition assume that both senders and receivers know the thresholds (or enough about those). That seems a bit odd to me, but I expect you've thought it through. Same thing with the averaging period I guess (though section 7 does specify a 30s default as a SHOULD). Or am I missing that one could calculate those from the various TLVs that are defined? (I think I'm also not understanding bullet point 4 in section 5 which may be related.) - section 3: I don't get what "cannot be used for fail-over purposes" means. I think you mean "ought not" since a receiver can do what they want in any case. - The security considerations of RFC 3630, from 2003, is 11 lines long. Has nothing affected OSPF security in the last decade+ that would be worth noting here? - In one response to the secdir review, [1] path shortening attacks were mentioned - I'm not clear myself if that's a deal here, but is text on that needed? [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05354.html
- [OSPF] Stephen Farrell's No Objection on draft-ie… Stephen Farrell
- Re: [OSPF] Stephen Farrell's No Objection on draf… Adrian Farrel
- Re: [OSPF] Stephen Farrell's No Objection on draf… Stephen Farrell
- Re: [OSPF] Stephen Farrell's No Objection on draf… John E Drake
- Re: [OSPF] Stephen Farrell's No Objection on draf… Acee Lindem (acee)
- Re: [OSPF] Stephen Farrell's No Objection on draf… Stephen Farrell
- Re: [OSPF] Stephen Farrell's No Objection on draf… John E Drake