Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)
draft-cheshire-dnsext-nbp-10

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>
Subject: Document Action: 'Requirements for a Protocol to Replace AppleTalk NBP' to Informational RFC (draft-cheshire-dnsext-nbp-09.txt)

The IESG has approved the following document:
- 'Requirements for a Protocol to Replace AppleTalk NBP'
  (draft-cheshire-dnsext-nbp-09.txt) as an Informational RFC

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

The IESG contact person is Ralph Droms.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-cheshire-dnsext-nbp/

Ballot Text

Technical Summary

   One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based
   Service Discovery (DNS-SD) was the desire to retire AppleTalk and the
   AppleTalk Name Binding Protocol, and to replace them with an IP-based
   solution. This document presents a brief overview of the capabilities
   of AppleTalk NBP, and outlines the properties required of an IP-based
   replacement.

Working Group Summary

   This was originally slated for the ZeroConf Working Group, 
   though was abandoned a long time ago. This requirements
   document is part of the "Bonjour" protocol set from Apple,
   which is now fairly widely used with multiple interoperable
   implementations. This is being published for the good of
   those in the community that wish to have a stable reference
   of how the protocol works, and why it was designed the way
   it was. 

Document Quality
   
   An earlier revision of this document  was reviewed by the IETF
   and the IESG.  The current revision has been updated based
   on feedback from the earlier reviews.  Ralph Droms reviewed
   the current revision.

Personnel
   
   Ralph Droms is the responsible AD.

RFC Editor Note