Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2012-08-22
21 (System) post-migration administrative database adjustment to the No Objection position for Chris Newman
2012-08-22
21 (System) post-migration administrative database adjustment to the Yes position for Magnus Westerlund
2008-09-30
21 (System) This was part of a ballot set with: draft-ietf-rserpool-common-param, draft-ietf-rserpool-enrp, draft-ietf-rserpool-policies
2008-07-31
21 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2008-07-31
21 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2008-07-31
21 (System) IANA Action state changed to In Progress from Waiting on Authors
2008-07-25
21 (System) IANA Action state changed to Waiting on Authors from In Progress
2008-07-22
21 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2008-07-21
21 (System) IANA Action state changed to In Progress
2008-07-21
21 Amy Vezza IESG state changed to Approved-announcement sent
2008-07-21
21 Amy Vezza IESG has approved the document
2008-07-21
21 Amy Vezza Closed "Approve" ballot
2008-07-18
21 Chris Newman [Ballot Position Update] Position for Chris Newman has been changed to No Objection from Discuss by Chris Newman
2008-07-16
21 Magnus Westerlund State Changes to IESG Evaluation::AD Followup from IESG Evaluation - Defer::AD Followup by Magnus Westerlund
2008-07-11
21 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-07-11
21 (System) New version available: draft-ietf-rserpool-asap-21.txt
2008-06-19
21 Cindy Morgan State Changes to IESG Evaluation - Defer::Revised ID Needed from IESG Evaluation - Defer by Cindy Morgan
2008-06-19
21 Chris Newman
[Ballot discuss]
I don't believe this document correctly uses TLS as an authentication
mechanism.  First, it does not say _how_ the domain name is encoded …
[Ballot discuss]
I don't believe this document correctly uses TLS as an authentication
mechanism.  First, it does not say _how_ the domain name is encoded
in client certificate subject.  It uses a lower case must for client
certificates.  I'll try to flesh this discuss out a bit more, but in
general I recommend looking at one of the documents applying TLS to
a specific protocol for examples in this area.  For example, RFC 4513
is a fairly recent and has a good "server identity check" section.

You would also need to create an equivalent "client identity check"
section if you're making client certificates the mandatory to implement
authentication mechanism for some scenarios.
2008-06-19
21 Chris Newman [Ballot Position Update] New position, Discuss, has been recorded by Chris Newman
2008-06-19
21 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2008-06-19
21 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2008-06-19
21 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2008-06-19
21 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2008-06-18
21 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2008-06-06
21 (System) Removed from agenda for telechat - 2008-06-05
2008-06-05
21 Jari Arkko
[Ballot comment]
draft-ietf-rserpool-asap-20.txt: No-Obj
=======================================

Comments:

Section 1:

  When SCTP [RFC4960] is used as the transport layer protocol, ASAP can
  …
[Ballot comment]
draft-ietf-rserpool-asap-20.txt: No-Obj
=======================================

Comments:

Section 1:

  When SCTP [RFC4960] is used as the transport layer protocol, ASAP can
  seamlessly incorporate the link-layer redundancy provided by SCTP.

Link layer? Its not just that. I think you mean ... the redundancy
provided by SCTP.

Section 2.2.2:

  Note that deregistration is NOT allowed by proxy, in other words a
  PE may only deregister itself.

I got confused here because at first I thought you had defined a
ASAP proxy role somewhere in the document. However, I think you
simply meant that the PE must de-register its own identifier.
I wonder how to check for this? Is the receiver tracking the
IP address of the sender of the register and de-register? Or
something else? If you can't test it, remove the statement.
Upon reading Section 3.2, I don't think I got any additional
clues about this.

Section 2.2.5:

  Note that if a new Home ENRP server is adopted any 'dynamic update
  request' will need to be resent to the new Home ENPR server if the
  endpoint would like to continue to receive updates.

How does the PU/PE know that a Home ENRP server has been added?

draft-ietf-rserpool-enrp-20.txt: No-Obj
=======================================

Section 3.2.1:

  Note, there is a very remote chance (about 1 in about 4 billion) that
  two ENRP servers in an operational scope will generate the same
  server Id and hence cause a server Id conflict in the pool.  However,
  no severe consequence of such a conflict has been identified.

Hmm. I thought that by the birthday paradox the chances of such a
conflict would be greater. Is there a recovery procedure upon a
conflict? Can the above text be modified to take into account the
paradox? Same issue exists in Section 3.1 of -asap.

draft-ietf-rserpool-common-param-17.txt: Yes
============================================

  This document is in good shape.

draft-ietf-rserpool-policies-09.txt: No-Obj
===========================================

  No comments.

All the documents:
==================

I am not particularly fond of the security mechanisms. They represent
the "hard-outside-soft-inside" security model. Outsiders will be
unable to pretend to be one of the parties. However, there are no
safeguards with nodes within the system becoming compromised or making
inappropriate actions for their role. For instance, the document does
not define or require the use of certificate fields to bind nodes into
particular addresses or PE/server identifiers.

As an interesting thought experiment, I wonder what RSERPOOL
security would have looked like, if it used HIP-like cryptographic
identities as server/pe identifiers?

However, I do not recommend the authors do anything abou this. Any
change here would be a major effort and not worth the time at this
stage.
2008-06-05
21 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2008-06-04
21 Cullen Jennings State Changes to IESG Evaluation - Defer from IESG Evaluation by Cullen Jennings
2008-06-04
21 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2008-06-02
21 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to Yes from Discuss by Magnus Westerlund
2008-05-30
21 Magnus Westerlund [Ballot discuss]
Holding a discuss for IANA until their questions has been resolved.
2008-05-30
21 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to Discuss from Yes by Magnus Westerlund
2008-05-30
21 Magnus Westerlund [Ballot Position Update] New position, Yes, has been recorded for Magnus Westerlund
2008-05-30
21 Magnus Westerlund Ballot has been issued by Magnus Westerlund
2008-05-30
21 Magnus Westerlund Created "Approve" ballot
2008-05-30
21 Magnus Westerlund Placed on agenda for telechat - 2008-06-05 by Magnus Westerlund
2008-05-30
21 Magnus Westerlund State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Magnus Westerlund
2008-05-29
21 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-05-29
20 (System) New version available: draft-ietf-rserpool-asap-20.txt
2008-05-21
21 Magnus Westerlund State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Magnus Westerlund
2008-05-08
21 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Ran Canetti.
2008-04-14
21 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-04-10
21 Amanda Baber
IANA Last Call comments:

IANA has questions:

- Can you please verify that Message Type 0x00 is reserved, but
types 0x0b-0xff are available for assignment? …
IANA Last Call comments:

IANA has questions:

- Can you please verify that Message Type 0x00 is reserved, but
types 0x0b-0xff are available for assignment? If so, please update
the document to reflect this.

- What scope of IPv6 multicast address do you need?

- Do you want/need a registry of the Message Delivery Options in
section 6.5.5?

Action 1:

Upon approval of this document, the IANA will create the following
registry "ASAP Message Types" located at http://www.iana.org/assignments/TBD

Registration Procedures: Specification Required
Initial contents of this registry will be:

Type Message Name Reference
----- ------------------------- ---------
0x00 (reserved by IETF) [RFC-rserpool-asap-19]
0x01 ASAP_REGISTRATION [RFC-rserpool-asap-19]
0x02 ASAP_DEREGISTRATION [RFC-rserpool-asap-19]
0x03 ASAP_REGISTRATION_RESPONSE [RFC-rserpool-asap-19]
0x04 ASAP_DEREGISTRATION_RESPONSE [RFC-rserpool-asap-19]
0x05 ASAP_HANDLE_RESOLUTION [RFC-rserpool-asap-19]
0x06 ASAP_HANDLE_RESOLUTION_RESPONSE [RFC-rserpool-asap-19]
0x07 ASAP_ENDPOINT_KEEP_ALIVE [RFC-rserpool-asap-19]
0x08 ASAP_ENDPOINT_KEEP_ALIVE_ACK [RFC-rserpool-asap-19]
0x09 ASAP_ENDPOINT_UNREACHABLE [RFC-rserpool-asap-19]
0x0a ASAP_SERVER_ANNOUNCE [RFC-rserpool-asap-19]
0x0b ASAP_COOKIE [RFC-rserpool-asap-19]
0x0c ASAP_COOKIE_ECHO [RFC-rserpool-asap-19]
0x0d ASAP_BUSINESS_CARD [RFC-rserpool-asap-19]
0x0e ASAP_ERROR [RFC-rserpool-asap-19]
0x0b-0xff Available for assignment [RFC-rserpool-asap-19]


Action 2:

Upon approval of this document, the IANA will make the following
changes in "PORT NUMBERS" registry located at
http://www.iana.org/assignments/port-numbers

OLD:

Keyword Decimal Description References
------- ------- ----------- ----------
asap-tcp 3863/tcp asap tcp port
asap-udp 3863/udp asap udp port
# Lyndon Ong  August 2003
asap-sctp 3863/sctp asap sctp
# Lyndon Ong  November 2005
asap-tcp-tls 3864/tcp asap/tls tcp port
# Lyndon Ong  August 2003
asap-sctp-tls 3864/sctp asap-sctp/tls
# Lyndon Ong  June 2006

NEW:

Keyword Decimal Description References
------- ------- ----------- ----------
asap-tcp 3863/tcp asap tcp port [RFC-rserpool-asap-19]
asap-udp 3863/udp asap udp port [RFC-rserpool-asap-19]
# Lyndon Ong  August 2003
asap-sctp 3863/sctp asap sctp [RFC-rserpool-asap-19]
# Lyndon Ong  November 2005
asap-tcp-tls 3864/tcp asap/tls tcp port [RFC-rserpool-asap-19]
# Lyndon Ong  August 2003
asap-sctp-tls 3864/sctp asap-sctp/tls [RFC-rserpool-asap-19]
# Lyndon Ong  June 2006


Action 3:

Upon approval of this document, the IANA will make the following
changes in "SCTP Parameters - RFC 2960" registry located at
http://www.iana.org/assignments/sctp-parameters
sub-registry "SCTP Payload Protocol Identifiers"

OLD:

11 - ASAP  [Ong]

NEW:

11 - ASAP [RFC-rserpool-asap-19]


Action 4:

Upon approval of this document, the IANA will make the following
assignments in the "Internet Multicast Addresses" registry located at
http://www.iana.org/assignments/multicast-addresses
sub-registry "224.0.1.0 - 224.0.1.255 (224.0.1/24) Internetwork Control Block"

224.0.1.[TBD] ASAP [RFC-rserpool-asap-19]


Action 5:

Upon approval of this document, the IANA will make the following
assignments in the "INTERNET PROTOCOL VERSION 6 MULTICAST
ADDRESSES" registry located at
http://www.iana.org/assignments/ipv6-multicast-addresses

[TBD -- need the scope of the multicast assignment]


We understand the above to be the only IANA Actions for this
document.
2008-04-03
21 Samuel Weiler Request for Last Call review by SECDIR is assigned to Ran Canetti
2008-04-03
21 Samuel Weiler Request for Last Call review by SECDIR is assigned to Ran Canetti
2008-03-31
21 Amy Vezza Last call sent
2008-03-31
21 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-03-31
21 Magnus Westerlund State Changes to Last Call Requested from AD Evaluation::AD Followup by Magnus Westerlund
2008-03-31
21 Magnus Westerlund Last Call was requested by Magnus Westerlund
2008-03-31
21 (System) Ballot writeup text was added
2008-03-31
21 (System) Last call text was added
2008-03-31
21 (System) Ballot approval text was added
2008-03-28
21 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-03-28
19 (System) New version available: draft-ietf-rserpool-asap-19.txt
2008-02-28
21 Magnus Westerlund [Note]: 'Before reading this ballot set please read draft-ietf-rserpool-overview' added by Magnus Westerlund
2008-02-18
21 Magnus Westerlund State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Magnus Westerlund
2008-02-18
21 Magnus Westerlund A few minor issues in ASAP regarding IANA Section still needs to be fixed.
2007-11-18
21 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-11-18
18 (System) New version available: draft-ietf-rserpool-asap-18.txt
2007-10-16
21 Magnus Westerlund State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Magnus Westerlund
2007-10-09
21 Magnus Westerlund State Changes to AD Evaluation from Publication Requested by Magnus Westerlund
2007-10-04
21 Magnus Westerlund [Note]: 'Doc Shepherd: Lyndon Ong' added by Magnus Westerlund
2007-10-04
21 Magnus Westerlund
RFC 4858 Writeup for ASAP, ENRP and Common Parameters specifications (draft-ietf-rserpool-asap-17.txt, draft-ietf-rserpool-enrp-17.txt and draft-ietf-rserpool-common-param-13.txt)

(1.a)  Who is the Document Shepherd for this …
RFC 4858 Writeup for ASAP, ENRP and Common Parameters specifications (draft-ietf-rserpool-asap-17.txt, draft-ietf-rserpool-enrp-17.txt and draft-ietf-rserpool-common-param-13.txt)

(1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

No Document Shepherd has been appointed for this document, the
Working Group Chairs are taking responsibility for reviewing and
Forwarding the document.

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

The documents have been reviewed by key WG members.

We have had a number of external comments, most particularly a detailed review and comments from Scott Bradner, former Transport AD.

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

No concerns that we know of.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

There are no IPR filings on any of these documents.

  (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?

There is strong WG consensus on these documents.

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

No one has threatened an appeal or otherwise objected.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

Nit checker has been run on the documents successfully.  We are submitting the
Protocol documents as experimental.  The overview and threats can be either
Informational or experimental.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

Yes, references are split as required. 

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

IANA considerations are documented in the ENRP, ASAP and Common Parameters drafts.  These are consistent with the bodies of the respective drafts.  The documents require that new registries be created for the ENRP and ASAP protocol parameters and provide initial contents of the registries plus allocation procedures for future registrations.  Naming and appropriate policies are called out for allocation of future values based on the Specification Required procedure defined in RFC 2434.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

There are no sections written in a formal language.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

Technical Summary

The three 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.

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.
2007-10-04
21 Magnus Westerlund State Changes to Publication Requested from AD is watching by Magnus Westerlund
2007-10-04
21 Magnus Westerlund Intended Status has been changed to Experimental from None
2007-09-22
17 (System) New version available: draft-ietf-rserpool-asap-17.txt
2007-07-10
16 (System) New version available: draft-ietf-rserpool-asap-16.txt
2007-01-11
15 (System) New version available: draft-ietf-rserpool-asap-15.txt
2006-10-20
21 (System) State Changes to AD is watching from Dead by system
2006-10-19
14 (System) New version available: draft-ietf-rserpool-asap-14.txt
2006-08-25
21 (System) State Changes to Dead from AD is watching by system
2006-08-25
21 (System) Document has expired
2006-07-26
21 Lars Eggert State Change Notice email list have been change to rserpool-chairs@tools.ietf.org from <lyong@ciena.com>, <maureen.stillman@nokia.com>
2006-04-05
21 Magnus Westerlund Shepherding AD has been changed to Magnus Westerlund from Jon Peterson
2006-02-09
21 (System) State Changes to AD is watching from Dead by system
2006-02-08
13 (System) New version available: draft-ietf-rserpool-asap-13.txt
2006-02-02
21 (System) State Changes to Dead from AD is watching by system
2006-02-02
21 (System) Document has expired
2005-07-20
12 (System) New version available: draft-ietf-rserpool-asap-12.txt
2005-02-21
11 (System) New version available: draft-ietf-rserpool-asap-11.txt
2004-10-15
10 (System) New version available: draft-ietf-rserpool-asap-10.txt
2004-06-10
09 (System) New version available: draft-ietf-rserpool-asap-09.txt
2003-10-27
08 (System) New version available: draft-ietf-rserpool-asap-08.txt
2003-05-16
07 (System) New version available: draft-ietf-rserpool-asap-07.txt
2003-03-29
21 Jon Peterson Shepherding AD has been changed to Peterson, Jon from Bradner, Scott
2003-03-03
06 (System) New version available: draft-ietf-rserpool-asap-06.txt
2002-11-04
05 (System) New version available: draft-ietf-rserpool-asap-05.txt
2002-10-16
21 Scott Bradner 2002-10-16 - update from chair
under discussion in WG
2002-10-16
21 Scott Bradner by sob
2002-07-03
04 (System) New version available: draft-ietf-rserpool-asap-04.txt
2002-05-07
21 Scott Bradner 2002-05-07 from Maureen Stillman
new version July, 2002
2002-05-07
21 Scott Bradner A new comment added
by sob
2002-05-03
03 (System) New version available: draft-ietf-rserpool-asap-03.txt
2002-04-27
21 Scott Bradner Draft Added by Scott Bradner
2002-03-04
02 (System) New version available: draft-ietf-rserpool-asap-02.txt
2001-11-29
01 (System) New version available: draft-ietf-rserpool-asap-01.txt
2001-06-01
00 (System) New version available: draft-ietf-rserpool-asap-00.txt