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