Operation of Anycast Services
draft-ietf-grow-anycast-04

I believe that the IESG did not follow a process consistent with how
we handle other documents and that the divergences from our normal
process created an unacceptably closed process.  As such, I am
abstaining on this document as I cannot support its publication under
the process that was used.

The area director described the process used as "hard ball."  He said
that because of the history of the document he was pushing back
against changes both from the IESG and late last call comments more so
than usual.  By history, I suspect that he meant both the fact that
this document has already been subject to an appeal and the fact that
the document has been under development for a long time.  I think that
the area director chose to play hard enough ball that the process can
no longer be considered open and that the IESG erred in supporting
this process and approving the document.

In particular, I believe that last call comments from Dean Anderson,
Sam Hartman, Lars Eggert, Eric Rescorla and David Oran were not given
due consideration.  IESG members received overly strong pushback
against discuss comments and the working group chair and area director
engaged in tactics that I found both intimidating and inimical to an
open discussion of the issues.  I have withdrawn my discuss not
because I believe that my discuss comments are in appropriate or have
been fixed but because absent an appeal, it would be undesirable to
spend more energy on this document.  The content isn't bad--my concern
is with the process.

The last call comments I'm complaining about were submitted after the
formal IETF last call had ended.  However it is very common for the
IESG to consider last call comments received after an IETF last call.
It is particularly common to consider comments received from IESG
members as last call comments even if they are not discuss ballots.
In this instance, the working group chair has created a high bar (new
WG last call and new IETF last call) for any changes that there is a
strong disincentive for any of these comments to be seriously
considered.  Even when several of the comments tended to focus on the
same sections of the document and to describe clarity problems,
authors said that they did not consider the change because they did
not see a problem.  The authors of a document are perhaps the worst
people to judge clarity of that document.  There was enough
commonality in comments that these comments should have at least been
referred to the WG if not the ietf list.

The handling of Dean Anderson's comments is particularly concerning.
These comments were delivered to the IESG in the form of an appeal.
The IESG chose to consider Dean's technical arguments as last call
comments and dismissed his appeal.  The IESG made no response to these
comments nor is it clear how much effort was spent considering these
technical comments.  Particularly considering that one of Dean's
reasons for choosing an appeal rather than a last call comment was
that he did not have faith that he could engage in a discussion and
actually get a response to his issues, it is concerning that he did
not in fact get such a response.  The fairness of the handling of
Dean's appeal depends critically on handling his technical comments
fairly and openly as last call comments.


Attached please find the discuss comments that I have withdrawn in the
interest of expedience and under protest.

Three discuss items:

1) It's not clear to me as a reader of this document whether it
intends to make a recommendation on whether DNS is an appropriate
application of anycast or simply to use operational experience with
DNS as a basis for research and other recommendations.  Based on the
history of this document and of discussions within the IETF, I think
ambiguity is harmful on this point.  I see three reasonable
resolutions.  First,  add a statement clearly indicating that this
document takes no position on the suitability of DNS as an anycast
application.  Second, refer to an existing IETF recommendation  on the
topic if there is one.  Finally, make an explicit statement that DNS
either does or does not  meet the recommendations of this document.  I
think the third solution is least preferred because I am not convinced
that making recommendations about specific applications is in scope
for this document.

2) Because of the history of this document, I think it likely that the
claims made in this document will be subjected to a higher level of
scrutiny than usual.  As such, I think we should hold ourselves to a
high standard of quality and only make claims for which we can cite
supporting research.  To that end, I'm not sure the following sentence
in 4.4.3 is sufficiently supported: " Consequently, in many cases it
is reasonable to consider networks making such use of PPLB to be
pathological."  (I suspect it is true, but question whether the
references in the two previous sentences are sufficient.)  In
particular, the document only claims that uses of PPLB *can cause*
*persistent packet reordering*.  That's not quite the same as claiming
that they *do cause* *persistent segment reordering*, which is the
condition that [Allman2000] requires.  In particular, consider under
what circumstances TCP flows where data is not sent in two directions
at the same time and PPLB is applied in the direction of ACKs will
actually meet the conditions of [Allman2000]?  I'm not just trying to
highlight this case, but any potential case in which the conclusion of
one sentence is not sufficient to support the pre-conditions of the
conclusion.  Does the analysis of [McCreary2000], [Fomenkov2004]
actually show that the TCP traffic on the Internet meets the
conditions necessary for re-ordering to be a problem?  If so, modify
the text to say this is the case.  If not, consider language like
"Consequently, making such use of PPLB may cause operational
problems."

3) The security review by Hilarie Orman claims that 6.1 should be
deleted because it is inadequately supported.  I concur.