Thank you, everyone, for a spirited discussion!
I've gone through the discussions and broken the emails down into a few categories - there were a number of emails on the document itself, many of them with helpful suggestions on how to improve / focus the document (thank you!).
More recently the discussion has become more acrimonious, and morphed from discussion **on this document** into the larger philosophical discussions on filtering in general, if what we have designed and call IPv6 can actually be implemented / deployed in the real world on core-type devices, what it means to claim compliance with a specification, the role of ISPs, ossification caused by operational decisions, "my network, my rules", etc.
The IETF LC thread on the document, and the TSVART review (and corresponding thread) both generated useful, and actionable comments, and I've asked the authors to go through them carefully and address them -- these fall into the "on the document" category. I think that once these have been done, the document itself will be in acceptable shape to proceed (but keep reading!)
There has been a significant amount of additional discussion after this - and it mostly falls into the "larger discussion" category.
It covers things such as:
* the implications of protocol design on implementability / deployability (can protocol X be deployed at scale?). Should feasibility of implementation in hardware be a consideration?
* the harms caused by filtering in the network (ossification, survivability of extensions, layering principles)
* operators need to perform filtering for end-point protection / DDoS mitigation / ECMP
* what it means to be compliant with a specification (if you can forward at rate X, but only filter at rate x/1,000,000 are you compliant?). If it is not possible to buy / build a device which filters at line rate, is that the fault of the vendor, the operator or the protocol design?
* do intermediate devices have any right to filter / role in filtering? If operators need to be able to do X to run their service / network, and they have to choose between "protocol correctness" and "keeping the network running", is it acceptable to drop / fold / spindle / mutilate correctness to keep the network up?
The discussion seems to have broken into 2 camps -- those who are saying that
1: the network / vendors should be able to do what the RFCs say,
vs
2: those who say that operational reality trumps RFCs.
This seems to be one of the tussles -- the other is (largely):
1: blocking unknown X is harmful to future protocols / development (blacklist approach)
vs
2: I run a [network / service / system] and know what packets I'm expecting. If I don't expect X, I'm just going to drop it (whitelist approach)
This same discussion has come up a number of times over the past few years -- "Why operators filter fragments" was one instance, the (multitude) of EH discussions were another.
It is clear that we are fairly far apart in many instances of this discussion, and it is worth further discussing the different philosophies. I feel that we should be discussing the architectural issues separately (not in the thread on this document). I also think that there is a fair bit of distance between the "operators" view and the "architecture" view.
I'm going to further investigate / discuss this, but I think that it might be worth:
* having some presentations / discussions on "how X works when deployed / implementation shortcomings". As an example, at the IEPG meeting in Yokohama (IETF94) these was a presentation on "MODERN ROUTER ARCHITECTURE FOR PROTOCOL DESIGNERS" - http://www.iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf . As another example, I was recently informed of a surprising limitation in TLS libraries -- these are apparently well known to those who work in this space, but I'd certainly never heard of them. I think that we (IETF participants in general) sometimes fall into believing that we know how technology X works because we've helped design it, but don't necessarily know what happens once it escapes our clutches / flies out of the nest.
* consider having a BoF on this / these topics.
* perhaps something like a workshop?
As for the current discussion, I'd like people to please:
a: step back and decided if you are simply repeating your current position (but in a new and louder voice) or if you are bringing something new to the topic.
b: move the discussion to this thread
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
---maf
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
---maf
