Skip to main content

Aggregate Server Access Protocol (ASAP)
draft-ietf-rserpool-asap-21

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    rserpool mailing list <rserpool@ietf.org>, 
    rserpool chair <rserpool-chairs@tools.ietf.org>
Subject: Document Action: 'Aggregate Server Access Protocol 
         (ASAP)' to Experimental RFC 

The IESG has approved the following documents:

- 'Aggregate Server Access Protocol (ASAP) '
   <draft-ietf-rserpool-asap-22.txt> as an Experimental RFC
- 'Endpoint Handlespace Redundancy Protocol (ENRP) '
   <draft-ietf-rserpool-enrp-22.txt> as an Experimental RFC
- 'Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace 
   Redundancy Protocol (ENRP) Parameters '
   <draft-ietf-rserpool-common-param-19.txt> as an Experimental RFC
- 'Reliable Server Pooling Policies '
   <draft-ietf-rserpool-policies-11.txt> as an Experimental RFC

These documents are products of the Reliable Server Pooling Working 
Group. 

The IESG contact persons are Magnus Westerlund and Lars Eggert.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rserpool-asap-22.txt

Ballot Text

Technical Summary

The four drafts provide a set of protocols and parameter definitions
supporting Reliable Server Pooling requirements, as defined in RFC 3237. 
ASAP defines a protocol for communication between server pool members and
server pool users that supports functions such as server registration and
lookup, liveness detection and limited failover.  ENRP defines a protocol
for communication between name resolution servers that supports a
fault-tolerant registry function for handling pool operation and
membership information.  Parameter formats and codepoint assignments for
both ASAP and ENRP are provided in a Common Parameters specification. The
Policies draft defines methods of applying the Rserpool protocols in order
to achieve a variety of different pool usage policies.


Working Group Summary

The Working Group process was constrained by the relatively small number
of people actively involved (although those involved were committed to
doing implementations of the protocols).  Otherwise there was little
controversy within the group.

Document Quality

There are multiple implementations of both ENRP and ASAP protocols,
thanks to participants.  However, there are no vendors that have indicated
plans for implementation.  Based on this and the limited number of
participants, Experimental track seems appropriate.  We received detailed
comments and review from Scott Bradner and his help was greatly
appreciated.

Personnel

Document Shepherding is being provided by the Working Group chairs,
Maureen Stillman and Lyndon Ong.  Responsible Area Director is Magnus
Westerland.

RFC-Editor Note:

Changes for

*
h
ttp://www.ietf.org/internet-drafts/draft-ietf-rserpool-common-param-17.txt


  - In the Parameter Types Table of Section 5.1 it should read
              |   0x11-0xfffffffe | (Available for assignment)   |
    instead of
              |   others   | (reserved by IETF)           |

  - In the Error Cause Table of Section 5.2 it should read
      |      0xb -0xffff      | (Available for assignment)     |
    instead of
      |      others      | reserved by IETF                    |

* http://www.ietf.org/internet-drafts/draft-ietf-rserpool-enrp-20.txt

  - In the Message Type table of Section 5.1 it should read
    0x0b-0xff (Available for assignment) RFCXXXX
    instead of
    0x0b-0xff (reserved by IETF) RFCXXXX

  - In the Update Action Types Table in Section 5.2 it should read
    0x0002-0xffff (Available for assignment) RFCXXXX
    instead of
    0x0002-0xffff (reserved by IETF) RFCXXXX

* http://www.ietf.org/internet-drafts/draft-ietf-rserpool-asap-20.txt

  - In the ASAP Message Types Table of Section 8.1 it should read
      0x0b-0xff  (Available for assignment)       RFCXXXX
    instead of
      0x0b-0xff  (reserved by IETF)               RFCXXXX

RFC Editor Note