Subject: [ANCP] Fwd: New Version Notification for draft-ietf-ancp-protocol-16

From: Tom Taylor <[email-masked]>
Date: Mon, 18 Apr 2011 21:15:47 -0400

An update to the ANCP base protocol draft has been submitted. The 
general outline of the changes required is on my Prague slides, at 
http://www.ietf.org/proceedings/80/slides/ancp-1.pdf. This covers the 
major part of the story, but there were a number of detailed editorial 
and occasionally technical changes. I'll provide a section-by-section 
analysis tomorrow.

Apologies to the rest of the authorial team by submitting this three 
hours earlier than I said I would, but I need the sleep :)

Tom Taylor

-------- Original Message --------
Subject: New Version Notification for draft-ietf-ancp-protocol-16
Date: Mon, 18 Apr 2011 18:05:28 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
CC: 
[email-masked],[email-masked],[email-masked],[email-masked]

A new version of I-D, draft-ietf-ancp-protocol-16.txt has been 
successfully submitted by Tom Taylor and posted to the IETF repository.

Filename:	 draft-ietf-ancp-protocol
Revision:	 16
Title:		 Protocol for Access Node Control Mechanism in Broadband Networks
Creation_date:	 2011-04-18
WG ID:		 ancp
Number_of_pages: 83

Abstract:
This document describes the Access Node Control Protocol (ANCP).
ANCP operates between a Network Access Server (NAS) and an Access
Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in
a multi-service reference architecture in order to perform QoS-
related, service-related and subscriber-related operations.  Use
cases for ANCP are documented in RFC 5851.  As well as describing the
base ANCP protocol, this document specifies capabilities for Digital
Subscriber Line (DSL) topology discovery, line configuration, and
remote line connectivity testing.  The design of ANCP allows for
protocol extensions in other documents if they are needed to support
other use cases and other access technologies.

ANCP is based on GSMPv3 (RFC 3292), but with many modifications and
extensions, to the point that the two protocols are not
interoperable.

The IETF Secretariat.