DNS SRV Resource Records for AFS
RFC 5864

Approval announcement
Draft of message to be sent after approval:

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>
Subject: Protocol Action: 'DNS SRV Resource Records for AFS' to Proposed Standard

The IESG has approved the following document:

- 'DNS SRV Resource Records for AFS '
   <draft-allbery-afs-srv-records-05.txt> as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Alexey Melnikov.

A URL of this Internet-Draft is:

Technical Summary

   This document specifies how to use DNS (Domain Name Service) SRV RRs
   (Resource Records) to locate services for the AFS distributed file
   system and how the priority and weight values of the SRV RR should be
   interpreted in the server ranking system used by AFS.  It deprecates
   use of the AFSDB RR to locate AFS cell database servers and provides
   guidance for backward compatibility.

Working Group Summary

   This is not a WG document.

   This document represents the consensus of the AFS community to
   deprecate the use of DNS AFSDB resource records to locate AFS
   database services, as described in RFC1183, in favor of using SRV
   records.  While the AFS protocols themselves are not the subject
   of any IETF work, this document is being advanced via the IETF
   because it updates previous IETF extensions to the DNS.

Document Quality

   Major AFS client implementors have indicated plans to implement
   support for use of SRV records as described by this document.
   In addition, a variety of developers and operators have indicated
   a desire to publish and use SRV records as described here.  There
   was substantial discussion surrounding the mapping of weight and
   priority information advertised via these records onto the server
   ranking system used by current AFS implementations, which resulted
   in the advice given in section 4.1.


   Jeffrey Hutzelman is the Document Shepherd.
   Alexey Melnikov is the Responsible Area Director.