Operation of Anycast Services
RFC 4786
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-12-20 |
04 | (System) | Received changes through RFC Editor sync (changed abstract to 'As the Internet has grown, and as systems and networked services within enterprises have become more … Received changes through RFC Editor sync (changed abstract to 'As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely. Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.') |
2015-10-14 |
04 | (System) | Notify list changed from gih@telstra.net, jabley@isc.org, kurtis@kurtis.pp.se to gih@telstra.net |
2012-08-22 |
04 | (System) | post-migration administrative database adjustment to the No Objection position for Cullen Jennings |
2012-08-22 |
04 | (System) | post-migration administrative database adjustment to the Abstain position for Sam Hartman |
2012-08-22 |
04 | (System) | post-migration administrative database adjustment to the No Objection position for Brian Carpenter |
2007-01-02 |
04 | Amy Vezza | [Note]: 'RFC 4786 BCP 126' added by Amy Vezza |
2007-01-02 |
04 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2007-01-02 |
04 | Amy Vezza | [Note]: 'RFC 4786' added by Amy Vezza |
2006-12-22 |
04 | (System) | RFC published |
2006-11-08 |
04 | (System) | Request for Early review by SECDIR Completed. Reviewer: Hilarie Orman. |
2006-11-08 |
04 | (System) | Request for Early review by SECDIR Completed. Reviewer: Rob Austein. |
2006-10-23 |
04 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2006-10-16 |
04 | Amy Vezza | IESG state changed to Approved-announcement sent |
2006-10-16 |
04 | Amy Vezza | IESG has approved the document |
2006-10-16 |
04 | Amy Vezza | Closed "Approve" ballot |
2006-10-15 |
04 | Sam Hartman | [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 … [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. |
2006-10-12 |
04 | Amy Vezza | [Ballot Position Update] Position for Sam Hartman has been changed to Abstain from Discuss by Amy Vezza |
2006-10-12 |
04 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza |
2006-10-12 |
04 | Brian Carpenter | [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Discuss by Brian Carpenter |
2006-10-12 |
04 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings |
2006-10-12 |
04 | Cullen Jennings | [Ballot discuss] I have cleared based on the advice and clarifications provided by routing ADs and the RFC editor notes. ----------------------------------- I would like to … [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. |
2006-10-12 |
04 | Bill Fenner | [Ballot Position Update] New position, Yes, has been recorded by Bill Fenner |
2006-10-11 |
04 | (System) | State Changes to IESG Evaluation from IESG Evaluation - Defer by system |
2006-10-10 |
04 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2006-10-09 |
04 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2006-10-06 |
04 | Brian Carpenter | [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 … [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. |
2006-10-06 |
04 | Brian Carpenter | [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 … [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? |
2006-10-06 |
04 | Brian Carpenter | [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 … [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. |
2006-10-06 |
04 | Brian Carpenter | [Ballot Position Update] New position, Discuss, has been recorded by Brian Carpenter |
2006-10-06 |
04 | Ted Hardie | [Ballot Position Update] New position, Yes, has been recorded by Ted Hardie |
2006-09-29 |
04 | (System) | Removed from agenda for telechat - 2006-09-28 |
2006-09-28 |
04 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2006-09-28 |
04 | Russ Housley | State Changes to IESG Evaluation - Defer from IESG Evaluation by Russ Housley |
2006-09-28 |
04 | Lisa Dusseault | [Ballot Position Update] New position, Abstain, has been recorded by Lisa Dusseault |
2006-09-28 |
04 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2006-09-28 |
04 | Jon Peterson | [Ballot comment] The presence of a Protocol Considerations sections, aside from being a bit anachronistic, seems odd when there are apparently no protocol considerations - … [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. |
2006-09-27 |
04 | Cullen Jennings | [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 … [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. |
2006-09-27 |
04 | Cullen Jennings | [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings |
2006-09-27 |
04 | Sam Hartman | [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 … [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. |
2006-09-27 |
04 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2006-09-27 |
04 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2006-09-27 |
04 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2006-09-27 |
04 | Dan Romascanu | [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 … [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. |
2006-09-27 |
04 | Dan Romascanu | [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 … [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. |
2006-09-26 |
04 | Sam Hartman | [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 … [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. |
2006-09-26 |
04 | Sam Hartman | [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 … [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. |
2006-09-26 |
04 | Sam Hartman | [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman |
2006-09-26 |
04 | Lars Eggert | [Ballot comment] Section 4.1., paragraph 0: > 4.1. Protocol Suitability It may be worth pointing out that protocols where transactions create state on … [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.) |
2006-09-26 |
04 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2006-09-21 |
04 | David Kessens | [Ballot Position Update] New position, Yes, has been recorded for David Kessens |
2006-09-21 |
04 | David Kessens | Ballot has been issued by David Kessens |
2006-09-21 |
04 | David Kessens | Created "Approve" ballot |
2006-09-21 |
04 | David Kessens | Placed on agenda for telechat - 2006-09-28 by David Kessens |
2006-09-21 |
04 | David Kessens | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by David Kessens |
2006-09-13 |
04 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2006-09-13 |
04 | Yoshiko Fong | IANA Last Call Comment-- As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2006-08-30 |
04 | Amy Vezza | Last call sent |
2006-08-30 |
04 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2006-08-29 |
04 | David Kessens | State Changes to Last Call Requested from Publication Requested::AD Followup by David Kessens |
2006-08-29 |
04 | David Kessens | Last Call was requested by David Kessens |
2006-07-10 |
04 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2006-07-10 |
04 | (System) | New version available: draft-ietf-grow-anycast-04.txt |
2006-07-09 |
04 | David Kessens | State Changes to Publication Requested::Revised ID Needed from Waiting for AD Go-Ahead by David Kessens |
2006-06-16 |
04 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2006-06-05 |
04 | Dinara Suleymanova | 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 … 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. |
2006-06-02 |
04 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2006-06-01 |
04 | David Kessens | Last Call was requested by David Kessens |
2006-06-01 |
04 | David Kessens | State Changes to Last Call Requested from AD is watching::AD Followup by David Kessens |
2006-06-01 |
04 | David Kessens | [Note]: 'PROTO Shepherd: Geoff Huston' added by David Kessens |
2006-06-01 |
04 | David Kessens | 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this … 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. |
2006-06-01 |
04 | David Kessens | State Change Notice email list have been change to gih@telstra.net, jabley@isc.org, kurtis@kurtis.pp.se from gih@telstra.net, dmm@1-4-5.net, jabley@isc.org, kurtis@kurtis.pp.se |
2006-06-01 |
04 | (System) | Ballot writeup text was added |
2006-06-01 |
04 | (System) | Last call text was added |
2006-06-01 |
04 | (System) | Ballot approval text was added |
2006-01-27 |
04 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2006-01-27 |
03 | (System) | New version available: draft-ietf-grow-anycast-03.txt |
2005-12-21 |
04 | David Kessens | State Changes to AD is watching::Revised ID Needed from Publication Requested by David Kessens |
2005-12-21 |
04 | David Kessens | Send my review to the authors and chairpeople, will need a new version. |
2005-12-21 |
04 | David Kessens | 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 |
2005-11-22 |
04 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
2005-10-21 |
02 | (System) | New version available: draft-ietf-grow-anycast-02.txt |
2005-07-20 |
01 | (System) | New version available: draft-ietf-grow-anycast-01.txt |
2005-02-16 |
00 | (System) | New version available: draft-ietf-grow-anycast-00.txt |