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

[Ballot comment]
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.

[Ballot discuss]
I have cleared based on the advice and clarifications provided by routing ADs and the RFC editor notes.

-----------------------------------

I would like to address the last call comment we have received
pointing out that if the routing is not stable, that protocols that
require more than a single request response won't work. I'm sure we
all agree with this.

The draft has approached this problem by limiting the usage of anycast
to situations where the routing is stable enough for the required
application. This can clearly be done in many cases but it does leave
me concerned about whether these applications will end up being
deployed in environments where this is no longer a valid assumption in
the future.

For example, the draft seems to imply that to say PPLB with different
nodes selected for anycast address are allowed in the internet but
that for some reason that won't happen due to TCP performance
concerns. I don't see how the point that out of order delivery impacts
TCP performance guarantees that people won't deploy networks that do
this. Even worse, I wonder if there are case where it might desirable
to deploy networks like this.

An alternative approach the draft could have taken was to limit the
usage of anycast to situations where only a single response was
used. I note that the draft considers protocols designs where the
single response could contain the non anycast ip address for the the
host sending the response such that a complex series of messages could
all be sent to that particular host with no concerns about routing
stability. For example, I have played with SIP anycast usages where
the initial SIP request is sent to the anycast address which always
responds with a 302 to redirect the SIP request to a non anycast
address.

I note that the draft takes the view that

  This document deliberately avoids prescribing rules as to which
  protocols or services are suitable for distribution by anycast; to
  attempt to do so would be presumptuous.

Instead it seems to make the presumption that the person deploying the
service can fully predict the total routing of all requests to this
service not just now but also in the future. Given the balance in IETF
between protocol designing and prescribing service deployment, I do
have some views on which type of presumption is mostly likely to be
effective.

I have entered this as a discuss only because I want to discuss it
with real routing experts (I'm not). I'm very much in favor of anycast
and in the end, I would like to be moving towards a position where RAI
protocols could use anycast as a discovery mechanism. I can imagine
the STUN work wanting an IANA defined address of a place to try and
find a STUN server - this is the sort of thing that would have to work
over any current or future routing system. I can imagine all the
various P2P systems interested in using this a bootstrap approach - it
has come up as a possibility in P2P-SIP for example.

[Ballot comment]
I would really like to see a separate more architectural document,
in the transport area or from the IAB. It would describe the impact of
route changes on sessions using anycast for various types of sessions,
such as command/response (e.g. DNS/UDP, SNMP/UDP), TCP, TLS, SCTP,
RTP and DCCP.

> 4.4.7.  Other Peoples' Networks
...
>    By way of mitigation, routing policies used by Anycast Nodes across
>    such routing systems should be conservative,

I don't understand what 'conservative' means.

> 4.4.8.  Aggregation Risks
...
>    In general, the scaling problems described here prevent anycast from
>    being a useful, general approach for service distribution on the
>    global Internet.  It remains, however, a useful technique for
>    distributing a limited number of Internet-critical services, as well
>    as in smaller networks where the aggregation concerns discussed here
>    do not apply.

This should be more prominent in the Introduction or in a Conclusion.

Minor
-----


> 6.1.  Denial-of-Service Attack Mitigation

This section gives two pro arguments, but not the obvious con:
if a DoS attack is distributed across multiple anycast servers,
much more coordination will be needed between those
servers to fight the attack.

> 6.3.  Service Hijacking
...
>    Many protocols which incorporate authentication or integrity
>    protection provide those features in a robust fashion, e.g. using
>    periodic re-authentication within a single session, or integrity
>    protection at either the channel (e.g.  [RFC2845], [RFC2487]) or
>    message (e.g.  [RFC4033], [RFC2311]) levels.  Protocols which are
>    less robust may be more vulnerable to session hijacking.

These are countermeasures against session hijacking, but the
section is only named 'service hijacking.'

> 7.  Protocol Considerations
>
>    This document does not impose any protocol considerations.

This section isn't needed.

[Ballot comment]
I would really like to see a separate more architectural document,
in the transport area or from the IAB. It would describe the impact of
route changes on sessions using anycast for various types of sessions,
such as command/response (e.g. DNS/UDP, SNMP/UDP), TCP, TLS, SCTP,
RTP and DCCP.

> 4.4.7.  Other Peoples' Networks
...
>    By way of mitigation, routing policies used by Anycast Nodes across
>    such routing systems should be conservative,

I don't understand what 'conservative' means.

> 4.4.8.  Aggregation Risks
...
>    In general, the scaling problems described here prevent anycast from
>    being a useful, general approach for service distribution on the
>    global Internet.  It remains, however, a useful technique for
>    distributing a limited number of Internet-critical services, as well
>    as in smaller networks where the aggregation concerns discussed here
>    do not apply.

This should be more prominent in the Introduction or in a Conclusion.

Minor
-----

> 2.  Terminology
...
>    Anycast Node: an internally-connected collection of hosts and routers
>      which together provide service for an anycast Service Address.  An
>      Anycast Node might be as simple as a single host participating in
>      a routing system with adjacent routers, or it might include a
>      number of hosts connected in some more elaborate fashion;

The word "connected" is pretty confusing since it seems to imply
separate physical connections between this set of nodes, which is
surely not right. Clearly they have to communicate, but that doesn't
imply special connections.

> 6.1.  Denial-of-Service Attack Mitigation

This section gives two pro arguments, but not the obvious con:
if a DoS attack is distributed across multiple anycast servers,
much more coordination will be needed between the operators of those
servers to fight the attack.

> 6.3.  Service Hijacking
...
>    Many protocols which incorporate authentication or integrity
>    protection provide those features in a robust fashion, e.g. using
>    periodic re-authentication within a single session, or integrity
>    protection at either the channel (e.g.  [RFC2845], [RFC2487]) or
>    message (e.g.  [RFC4033], [RFC2311]) levels.  Protocols which are
>    less robust may be more vulnerable to session hijacking.

Exactly - these are countermeasures against session hijacking, but the
section is named 'service hijacking.' What are the countermeasures against
a bogus node simply offering a bogus version of the service?

> 7.  Protocol Considerations
>
>    This document does not impose any protocol considerations.

This section does not impose any knowledge. What is it for?

[Ballot discuss]
I'd like to propose this short Discuss with a proposed resolution
as an alternative to Cullen's rather longer Discuss.

> 4.1.  Protocol Suitability
...
>    This document deliberately avoids prescribing rules as to which
>    protocols or services are suitable for distribution by anycast; to
>    attempt to do so would be presumptuous.

That is well understood, but I believe there is a missing warning here,
along these lines:

Operators should be aware that, especially for long running flows,
there are potential failure modes that are more complex than
a simple 'destination unreachable' failure.

[Ballot comment]
The presence of a Protocol Considerations sections, aside from being a bit anachronistic, seems odd when there are apparently no protocol considerations - I'm not sure what message the existence of this section is intended to convey. This is not a required section like IANA or Security Considerations in the I-D Checklist, as far as I can see.

[Ballot discuss]
I would like to address the last call comment we have received
pointing out that if the routing is not stable, that protocols that
require more than a single request response won't work. I'm sure we
all agree with this.

The draft has approached this problem by limiting the usage of anycast
to situations where the routing is stable enough for the required
application. This can clearly be done in many cases but it does leave
me concerned about whether these applications will end up being
deployed in environments where this is no longer a valid assumption in
the future.

For example, the draft seems to imply that to say PPLB with different
nodes selected for anycast address are allowed in the internet but
that for some reason that won't happen due to TCP performance
concerns. I don't see how the point that out of order delivery impacts
TCP performance guarantees that people won't deploy networks that do
this. Even worse, I wonder if there are case where it might desirable
to deploy networks like this.

An alternative approach the draft could have taken was to limit the
usage of anycast to situations where only a single response was
used. I note that the draft considers protocols designs where the
single response could contain the non anycast ip address for the the
host sending the response such that a complex series of messages could
all be sent to that particular host with no concerns about routing
stability. For example, I have played with SIP anycast usages where
the initial SIP request is sent to the anycast address which always
responds with a 302 to redirect the SIP request to a non anycast
address.

I note that the draft takes the view that

  This document deliberately avoids prescribing rules as to which
  protocols or services are suitable for distribution by anycast; to
  attempt to do so would be presumptuous.

Instead it seems to make the presumption that the person deploying the
service can fully predict the total routing of all requests to this
service not just now but also in the future. Given the balance in IETF
between protocol designing and prescribing service deployment, I do
have some views on which type of presumption is mostly likely to be
effective.

I have entered this as a discuss only because I want to discuss it
with real routing experts (I'm not). I'm very much in favor of anycast
and in the end, I would like to be moving towards a position where RAI
protocols could use anycast as a discovery mechanism. I can imagine
the STUN work wanting an IANA defined address of a place to try and
find a STUN server - this is the sort of thing that would have to work
over any current or future routing system. I can imagine all the
various P2P systems interested in using this a bootstrap approach - it
has come up as a possibility in P2P-SIP for example.

[Ballot discuss]
[Updated to correct an error in item 2]

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 IETFrecommendation  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.

[Ballot comment]
I find the information in Section 5 Service Management quite insufficient. It is hard to talk about service management and monitoring without being clear what are the characteristics of the service that are important and the associated metrics. There is some text in other sections about availability and response time, but this is not enough. I would have also liked to have more exact references to IPPM metrics that are relevant for anycast service measurements listed here, rather than just examples of tools that may have not persist or may change during the life cycle of this BCP.

[Ballot comment]
I find the information in Section 5 Service Management quite insufficient. It i shard to talk about service management and monitoring without being clear what are the characteristics of the service that are important and the associated metrics. There is some text in other sections about availability and response time, but this is not enough. I would have also liked to have more exact references to IPPM metrics that are relevant for anycast service measurements listed here, rather than just examples of tools that may have not persist or may change during the life cycle of this BCP.

[Ballot comment]
I support Larz's comment.  Another kind of state that anycas
applications need to be aware of is information cached in a client
about a server's capabilities.  For example section 4.5.4 of RFC 2671
recommends clients cache (for one transaction) information about how
large of a request servers can handle.
That's almost certainly OK.
Longer term caching of capability information would require  that the information be consistent between anycast nodes.

[Ballot discuss]
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 IETFrecommendation  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 will actually meet the conditions of [Allman2000]?
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.

[Ballot comment]
Section 4.1., paragraph 0:
>  4.1.  Protocol Suitability

  It may be worth pointing out that protocols where transactions create
  state on the server may more problematic to deploy with anycast than
  query-only protocols. A series of transactions that creates and acts
  on server state will fail if anycast routing changes during its
  processing (and the replication mechanism between anycast servers
  hasn't propagated the state yet). Or maybe that's too fine a point?
  (Is also related to Section 4.6.)

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication? Which chair is the WG
Chair Shepherd for this document?


Yes, the document has been reviewed by the GROW WG Chair.

The document is, I believe, ready to forward to the IESG for
publication. (There are a number of issues of currency of
references (BGP, IPV6 address architecture) and some issues of
style that I believe will be caught by the RFC Editor.)

Geoff Huston is the WG Chair Shepherd for this document



1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

The document has had extensive review by the GROW WG across 2005,
and generated considerable volume of discussion. I have no
residual concerns about the review process for this document.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, internationalization,
XML, etc.)?

The document has been reviewed from an applications design
perspective, and, in particular, from the perspective of deployment
of DNS services. I do not believe that additional review of the
document from an applications perspective is warranted


1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

There was a single dissenting view from Dean Anderson noting a
difference in semantic interpretation of 'node selection',
differences in capabilities of 'Per-Packet Load Balancing', and
differences of view in the potential for TCP failure over parallel
diverse paths with Per-Packet Load Balancing. Dean noted that the
chairs had judged WG consensus for publication of this document and
that he did not dispute that judgment.

The following WG postings refer to this dialog:

http://darkwing.uoregon.edu/~llynch/grow/msg00426.html
http://darkwing.uoregon.edu/~llynch/grow/msg00427.html
http://darkwing.uoregon.edu/~llynch/grow/msg00428.html
http://darkwing.uoregon.edu/~llynch/grow/msg00430.html
http://darkwing.uoregon.edu/~llynch/grow/msg00431.html
http://darkwing.uoregon.edu/~llynch/grow/msg00432.html
http://darkwing.uoregon.edu/~llynch/grow/msg00433.html

To quote from the final message in this thread:

"I think you are being over-literal, and judging from the
response (or non-response) of others I think your objections to
this turn of phrase are not widely shared.

Note that the process we are participating in is one of rough
consensus and not universal agreement."

I have seen no further working group postings on this draft during
the WG last call period, and no observed working group consensus to
create another revision of this draft.

Dean Andersen's response to this summary was: "Rather, my interest
now is to record that there were objections raised at the time.
I'm willing to acknowledge that these objections were a minority
view. I appreciate your attention to the accuracy of the record."


1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The document has been reviewed by a number of WG members and there
appears to be solid support for consensus on this document to
proceed with publication as a BCP. There was one dissenting view
(Dean Anderson), and a number of responses to this dissenting view
that clearly indicated a rough consensus in favor of publication
of this document.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email to the Responsible Area Director. (It should be
separate email because this questionnaire will be entered into
the tracker).

Not to my knowledge.


1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

Yes - no nits have been found and the document checks against the
online nits checked.

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publication). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area Director in
the Last Call downref procedure specified in RFC 3967.


References are split into normative and informative references.

The reference to the IPv6 address architecture draft needs to be
updated to a reference to RFC4291. This can be undertaken in the
RFC Editor stage. Also the reference to BGP needs to be updated to
RFC4271. Again this can be performed by the RFC Editor.

As this is a proposed BCP there is no downward normative
references.



1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:

* Technical Summary

This document describes the use of anycast for both local scope
distribution of services using an Interior Gateway Protocol and
global distribution using BGP. Many of the issues for
monitoring and data synchronisation are common to both, but
deployment issues differ substantially.

The document considers the design of anycast services, including
considerations of protocol suitability, routing considerations,
addressing considerations and multi-service configurations, as
well as service management issues.


* Working Group Summary

The document was adopted as a GROW WG document in February 2005,
and further revised in accordance with WG comments. The Working
Group Last Call was conducted in November 2005, and a further
revision of the document was published in January 2006.

The WG position was a general consensus, with some residual
points of dissension within the working group from a single
party. There was no controversy about the process, and all WG
members accepted the call of rough consensus to proceed with a
publication request.


* Protocol Quality

The document describes the advantages and limitations of a
commonly used service deployment technique.

Anycast has been widely deployed in a number of scenarios,
particularly relating to the deployment of DNS servers.

Anycast does not require specific support from equipment
vendors.


1.j) Please provide such a write-up. Recent examples can be found in
the "Action" announcements for approved documents.

see above

1.k) Note:

* The relevant information for the technical summary can
frequently be found in the abstract and/or introduction of
the document. If not, this may be an indication that there
are deficiencies in the abstract or introduction.

* For the Working Group Summary: Was there anything in WG
process that is worth noting? For example, was there
controversy about particular points, decisions where
consensus was particularly rough, etc.

* For the protocol quality, useful information includes:

+ Are there existing implementations of the protocol?

+ Have a significant number of vendors indicated they
plan to implement the specification?

+ Are there any reviewers that merit special mention as
having done a thorough review (i.e., that resulted in
important changes or a conclusion that the document
had no substantive issues)?

noted

The questionnaire and write-up is sent to the AD and
iesg-secretary@ietf.org with a request to publish the document. The
questionnaire and write-up, minus any discussion of possible appeals,
is also sent to the working group mailing list. The questionnaire
indicates which chair will be the WG Chair Shepherd. This
information should be entered into the ID Tracker (where it goes is
in flux). In addition to making life easier for the ADs, this is
important for the IETF Chair's Gen-ART [GEN-ART] Directorate and
other directorates, so they can know where to address reviews in
addition to the Responsible Area Director.

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?  Which chair is the WG
        Chair Shepherd for this document?


        Yes, the document has been reviewed by the GROW WG Chair.

        The document is, I believe, ready to forward to the IESG for
        publication. (There are a number of issues of currency of
        references (BGP, IPV6 address architecture) and some issues of
        style that I believe will be caught by the RFC Editor.)

        Geoff Huston is the WG Chair Shepherd for this document



  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?
        The document has had extensive review by the GROW WG across 2005,
        and generated considerable volume of discussion. I have no
        residual concerns about the review process for this document.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, internationalization,
        XML, etc.)?

        The document has been reviewed from an applications design
        perspective, and, in particular, from the perspective of deployment
        of DNS services. I do not believe that additional review of the
        document from an applications perspective is warranted


  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

        There was a single dissenting view from Dean Anderson noting a
        difference in semantic interpretation of 'node selection',
        differences in capabilities of 'Per-Packet Load Balancing', and
        differences of view in the potential for TCP failure over parallel
        diverse paths with Per-Packet Load Balancing. Dean noted that the
        chairs had judged WG consensus for publication of this document and
        that he did not dispute that judgment.

        The following WG postings refer to this dialog:

        http://darkwing.uoregon.edu/~llynch/grow/msg00426.html
        http://darkwing.uoregon.edu/~llynch/grow/msg00427.html
        http://darkwing.uoregon.edu/~llynch/grow/msg00428.html
        http://darkwing.uoregon.edu/~llynch/grow/msg00430.html
        http://darkwing.uoregon.edu/~llynch/grow/msg00431.html
        http://darkwing.uoregon.edu/~llynch/grow/msg00432.html
        http://darkwing.uoregon.edu/~llynch/grow/msg00433.html

        To quote from the final message in this thread:

          "I think you are being over-literal, and judging from the
          response (or non-response) of others I think your objections to
          this turn of phrase are not widely shared.

          Note that the process we are participating in is one of rough
          consensus and not universal agreement."

        I have seen no further working group postings on this draft during
        the WG last call period, and no observed working group consensus to
        create another revision of this draft.

        Dean Andersen's response to this summary was: "Rather, my interest
        now is to record that there were objections raised at the time.
        I'm willing to acknowledge that these objections were a minority
        view. I appreciate your attention to the accuracy of the record."

  1.e) How solid is the WG consensus behind this document?  Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

        The document has been reviewed by a number of WG members and there
        appears to be solid support for consensus on this document to
        proceed with publication as a BCP. There was one dissenting view
        (Dean Anderson), and a number of responses to this dissenting view
        that clearly indicated a rough consensus in favor of publication
        of this document.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarize the areas of conflict in
        separate email to the Responsible Area Director.  (It should be
        separate email because this questionnaire will be entered into
        the tracker).

        Not to my knowledge.

  1.g) Have the chairs verified that the document checks out against
        all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
        Boilerplate checks are not enough; this check needs to be
        thorough.

        Yes - no nits have been found and the document checks against the
        online nits checked.

  1.h) Has the document split its references into normative and
        informative?  Are there normative references to IDs, where the
        IDs are not also ready for advancement or are otherwise in an
        unclear state?  The RFC Editor will not publish an RFC with
        normative references to IDs (will delay the publication until
        all such IDs are also ready for RFC publication).  If the
        normative references are behind, what is the strategy for their
        completion?  On a related matter, are there normative references
        that are downward references, as described in BCP 97, RFC 3967
        RFC 3967 [RFC3967]?  Listing these supports the Area Director in
        the Last Call downref procedure specified in RFC 3967.

        References are split into normative and informative references.

        The reference to the IPv6 address architecture draft needs to be
        updated to a reference to RFC4291. This can be undertaken in the
        RFC Editor stage. Also the reference to BGP needs to be updated to
        RFC4271. Again this can be performed by the RFC Editor.

        As this is a proposed BCP there is no downward normative
        references.



  1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

          This document describes the use of anycast for both local scope
          distribution of services using an Interior Gateway Protocol and
          global distribution using BGP.  Many of the issues for
          monitoring and data synchronisation are common to both, but
          deployment issues differ substantially.

          The document considers the design of anycast services, including
          considerations of protocol suitability, routing considerations,
          addressing considerations and multi-service configurations, as
          well as service management issues.


        *    Working Group Summary

          The document was adopted as a GROW WG document in February 2005,
          and further revised in accordance with WG comments. The Working
          Group Last Call was conducted in November 2005, and a further
          revision of the document was published in January 2006.

          The WG position was a general consensus, with some residual
          points of dissension within the working group from a single
          party. There was no controversy about the process, and all WG
          members accepted the call of rough consensus to proceed with a
          publication request.

State Change Notice email list have been change to gih@telstra.net, dmm@1-4-5.net, jabley@isc.org, kurtis@kurtis.pp.se from gih@telstra.net, isoc-contact@aarnet.edu.au, dmm@1-4-5.net, dmm@uoregon.edu, dmm@cisco.com