thank you > There are quite a lot of changes there and I'm going to make a bunch > of specific comments about the text changes in this ID in separate > emails, but want to say some more general things first. > > First and foremost, bcp194 needs an update, so thanks for taking up > the gauntlet on this - it's very welcome. > > The main concern I have is that BCP194 is a document which is already > referenced in national telecommunications security policies, and which > will become more widely referenced in future, as the world moves > towards risk-management based approaches to telecoms security. > > From this point of view, the IETF needs to be careful about what's put > into the document, and more importantly, what's not put in the > document. There are plenty of potentially useful additions in the > current round of updates, but for a document update of this type, > future amendments need to be added sparingly, and should be > conservative and principle-based in approach, rather than getting too > detailed about implementation specifics. > > In other words, I'd be in favour of the approach that the best outcome > will be not when there's nothing left to add, but when there's nothing > more that can be taken away. > > In terms of the draft as it currently stands, I have concerns about > the following areas of principal (in no particular order): > > - scope creep: the abstract has moved from "describes measures to > protect" to "This document provides a comprehensive list". I don't > think that this is a wise move either to claim this or to aim in > this direction. > > - there are experimental / development ideas in there which are not > widely used on production networks, and therefore inappropriate for > BCP status, e.g. ASPA (still undergoing protocol behavioral change > at the ietf in SIDROPS), RFC5549, etc. There's a mention of TCP-MD5 > but using SHA1/SHA512 instead of MD5, which I'm not sure even > exists. > > - stuff which is bgp stack implementation dependent: e.g. Idempotency > for Prefix filter Changes, prefix ruleset optimisation, etc. > > - defining / redefining well known terms (most of section 3). > > - being overly prescriptive, e.g. "9.2.1.1. Inbound Filtering" or > "9.1.2. Order of Prefixfilters". All this is too detailed. > > - things which don't really need to be mentioned, or if they do, then > by reference only. e.g. "7.1.3. Recursively Computing Filters", or > using BGP communities to signal ROV state (should reference > draft-rpki-communities-harmful instead). > > - things which seem like they're a good idea on first glance, > e.g. "operators SHOULD NOT set a higher local preference for NLRI > received via an IXP RS": no document is going to stop people from > using localpref at IXPs, and other operators are going to drain > traffic via RSs by draining prefixes from RSs, not by increasing the > as-path length. Or e.g. recommending route flap dampening: we need > extensive production telemetry to ensure that this is actually a > good idea. The last time it was turned on globally, a lot of damage > was done. > > - things which are ephemeral. This is a document where everything > that's written in it should be relevant in 10-20 years time. > E.g. "Recently, an attack was observed", or section 6.3. notes "at > the time of writing of this document" and suggests /24 + /48 for > ipv4 / ipv6 prefixes lengths for interdomain routing. But for > example, a well-known CDN has been announcing more specific prefixes > over interdomain bgp sessions for several years. > > - less is more. > > These are general principles which should be kept in mind when writing > text, i.e. the above isn't intended to be an exhaustive list of issues > with the document. > > I'll take up specific items in separate email threads. > > Nick > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
