From Sven.Ooghe@alcatel-lucent.be Mon May 4 00:34:22 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98C1E3A6ABA for ; Mon, 4 May 2009 00:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=2.776, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZx7kkRfm-xd for ; Mon, 4 May 2009 00:34:21 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 4E5613A69D0 for ; Mon, 4 May 2009 00:34:20 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n447Za2F006433; Mon, 4 May 2009 09:35:36 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 09:35:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CC8A.E9FBCC94" Date: Mon, 4 May 2009 09:35:33 +0200 Message-ID: <7168964CAC5C144685272595141B6DBA022F27FB@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Framework draft question Thread-Index: Acm2vVE7MxPMo20zQvaJjXUtx/LJ1gCNsybAAPvwWyAACMAZ0APgjqkA References: <7168964CAC5C144685272595141B6DBA020E79ED@FRVELSMBS22.ad2.ad.alcatel.com> <5661758E3E93364685B91DD8272F28760117D622@S4DE8PSAAQC.mitte.t-com.de> From: "OOGHE Sven" To: "Wojciech Dec (wdec)" , , X-OriginalArrivalTime: 04 May 2009 07:35:36.0641 (UTC) FILETIME=[EA5EE310:01C9CC8A] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Subject: Re: [ANCP] Framework draft question X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 07:34:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CC8A.E9FBCC94 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Woj, Thomas, =20 In my view, the requirement is basically saying that it must not hamper fast completion of ANCP operations when required. I cannot find anything in the protocol that would result in a slow completion of an operation. =20 Are you aware of specific timers that would result in slow transactions? If not, I think it's better to refer to the behavior of the nodes that run the ANCP protocol. =20 I propose to reword the requirement to: =20 - The Access Node must be designed to allow fast completion of ANCP operations, in the order of magnitude of tens of milliseconds. - The NAS must be designed to allow fast completion of ANCP operations, in the order of magnitude of tens of milliseconds. =20 Let me know if you are ok with this. =20 Regards, Sven ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: dinsdag 14 april 2009 15:50 To: HaagT@telekom.de; OOGHE Sven; ancp@ietf.org Subject: RE: [ANCP] Framework draft question The performance of even the most optimized implementation of a protocol on an OS, a generic CPU and I/O platform will degrade with the messaging load. Hence what guideline is being provided here is doubtful. I don't quite know who would develop any an implementation that was purposefully slow, and it's equally doubtful as to what would happen should the 10s of ms requirement below not be met (will the protocol break? Will the use-fullness of the protocol disappear?) =20 Cheers, Woj. ________________________________ From: HaagT@telekom.de [mailto:HaagT@telekom.de]=20 Sent: 14 April 2009 11:36 To: Wojciech Dec (wdec); Sven.Ooghe@alcatel-lucent.be; ancp@ietf.org Subject: AW: [ANCP] Framework draft question =09 =09 Hi, =20 you're right that this is a performance requirement.=20 But I think this is an important requirement which has impact on protocol design and gives some developing guideline.=20 So I would propose to keep it. =20 Regards =20 Thomas ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec (wdec) Gesendet: Donnerstag, 9. April 2009 11:21 An: OOGHE Sven; ancp@ietf.org Betreff: Re: [ANCP] Framework draft question =09 =09 FWIW, my opinion is that this requirement isn't for a framework as it is a performace requirement that depends on a large number of things. I'd say drop. =20 -Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of OOGHE Sven Sent: 06 April 2009 15:41 To: ancp@ietf.org Subject: [ANCP] Framework draft question =09 =09 Hi,=20 I would like to raise a question regarding draft-ietf-ancp-framework-08.=20 Section 4.1 states "The ANCP MUST allow fast completion of a given operation, in the order of magnitude of tens of milliseconds."=20 This is as such not a protocol requirement, but rather a requirement on the platform choice (e.g. CPU speed).=20 I am soliciting feedback what to do with this (drop / reword / keep).=20 Regards,=20 Sven=20 ------_=_NextPart_001_01C9CC8A.E9FBCC94 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Framework draft question
Woj, Thomas,
 
In my view, the requirement is basically = saying that it=20 must not hamper fast completion of ANCP operations when required. I = cannot find=20 anything in the protocol that would result in a slow completion of an=20 operation.
 
Are you aware of specific timers that would = result in=20 slow transactions? If not, I think it's better to refer to the=20 behavior of the nodes that run the ANCP=20 protocol.
 
I propose to reword the requirement=20 to:
 
- The Access Node must be designed to allow = fast=20 completion of ANCP operations, in the order of magnitude of tens of=20 milliseconds.
- The NAS must be designed to allow fast = completion of=20 ANCP operations, in the order of magnitude of tens of=20 milliseconds.
 
Let me=20 know if you are ok with this.
 
Regards,
Sven
From: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Sent: dinsdag 14 april 2009=20 15:50
To: HaagT@telekom.de; OOGHE Sven;=20 ancp@ietf.org
Subject: RE: [ANCP] Framework draft=20 question

The performance of even the most optimized implementation of a = protocol=20 on an OS, a generic CPU and I/O platform will degrade with the = messaging load. Hence what guideline is being provided here is = doubtful. I=20 don't quite = know who=20 would develop any an implementation that was purposefully slow, and it's = equally=20 doubtful as to what would happen should the 10s of ms requirement below = not be=20 met (will the protocol break? Will the use-fullness of the protocol=20 disappear?)
 
Cheers,
Woj.

From: HaagT@telekom.de=20 [mailto:HaagT@telekom.de]
Sent: 14 April 2009 = 11:36
To:=20 Wojciech Dec (wdec); Sven.Ooghe@alcatel-lucent.be;=20 ancp@ietf.org
Subject: AW: [ANCP] Framework draft=20 question

Hi,
 
you're right that this  is a performance = requirement.
But I think this is an important requirement = which has=20 impact on protocol design and gives some developing guideline.=20
So I would propose to keep = it.
 
Regards
 
Thomas

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec=20 (wdec)
Gesendet: Donnerstag, 9. April 2009 = 11:21
An: OOGHE=20 Sven; ancp@ietf.org
Betreff: Re: [ANCP] Framework draft=20 question

FWIW, my opinion is that this requirement isn't for a = framework as=20 it is a performace requirement that depends on a large number of = things. I'd=20 say drop.
 
-Woj.

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of OOGHE=20 Sven
Sent: 06 April 2009 15:41
To:=20 ancp@ietf.org
Subject: [ANCP] Framework draft=20 question

Hi,

I would like to raise a question = regarding=20 draft-ietf-ancp-framework-08.

Section 4.1 states "The ANCP MUST = allow fast=20 completion of a given operation, in the order of magnitude of tens = of=20 milliseconds."

This is as such not a protocol = requirement, but=20 rather a requirement on the platform choice (e.g. CPU speed). =

I am soliciting feedback what to do = with this=20 (drop / reword / keep).

Regards,
Sven

------_=_NextPart_001_01C9CC8A.E9FBCC94-- From wdec@cisco.com Mon May 4 00:43:08 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DDAB3A6832 for ; Mon, 4 May 2009 00:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.82 X-Spam-Level: X-Spam-Status: No, score=-9.82 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zk3j0AhgIQtH for ; Mon, 4 May 2009 00:43:02 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 49D3D3A6AF1 for ; Mon, 4 May 2009 00:42:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,291,1238976000"; d="scan'208,217";a="39684620" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 May 2009 07:43:53 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n447hrgs001310; Mon, 4 May 2009 09:43:53 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n447hrWp007670; Mon, 4 May 2009 07:43:53 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 09:43:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CC8C.12795852" Date: Mon, 4 May 2009 09:43:51 +0200 Message-ID: In-Reply-To: <7168964CAC5C144685272595141B6DBA022F27FB@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Framework draft question Thread-Index: Acm2vVE7MxPMo20zQvaJjXUtx/LJ1gCNsybAAPvwWyAACMAZ0APgjqkAAACzuWA= References: <7168964CAC5C144685272595141B6DBA020E79ED@FRVELSMBS22.ad2.ad.alcatel.com><5661758E3E93364685B91DD8272F28760117D622@S4DE8PSAAQC.mitte.t-com.de> <7168964CAC5C144685272595141B6DBA022F27FB@FRVELSMBS22.ad2.ad.alcatel.com> From: "Wojciech Dec (wdec)" To: "OOGHE Sven" , , X-OriginalArrivalTime: 04 May 2009 07:43:53.0693 (UTC) FILETIME=[12A300D0:01C9CC8C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15299; t=1241423033; x=1242287033; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20Framework=20draft=20question |Sender:=20; bh=lFrqsYYzkxTKkImhQFkRsnbu66Oj/DGpfWzVaOkjscU=; b=EdFBPGBK0cp2uw/CQ7c7s+eMzbeTnSC5VrMjlbZEzsaRwpctRxtzZ0lU1+ 0h0mgMd1hmukWK2xcTbvniW6ItdRHKQFTdD7RAOdYZPCYcr0Na1F9MNhtKd7 xbgfPoCbz1; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [ANCP] Framework draft question X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 07:43:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CC8C.12795852 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sven, =20 that's fine by me. As soon as we close this one, please publish an updated version of the draft which we will then launch into the next step of the review process. =20 Cheers, Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of OOGHE Sven Sent: 04 May 2009 09:36 To: Wojciech Dec (wdec); HaagT@telekom.de; ancp@ietf.org Subject: Re: [ANCP] Framework draft question =09 =09 Woj, Thomas, =20 In my view, the requirement is basically saying that it must not hamper fast completion of ANCP operations when required. I cannot find anything in the protocol that would result in a slow completion of an operation. =20 Are you aware of specific timers that would result in slow transactions? If not, I think it's better to refer to the behavior of the nodes that run the ANCP protocol. =20 I propose to reword the requirement to: =20 - The Access Node must be designed to allow fast completion of ANCP operations, in the order of magnitude of tens of milliseconds. =09 - The NAS must be designed to allow fast completion of ANCP operations, in the order of magnitude of tens of milliseconds. =20 Let me know if you are ok with this. =20 Regards, Sven =09 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: dinsdag 14 april 2009 15:50 To: HaagT@telekom.de; OOGHE Sven; ancp@ietf.org Subject: RE: [ANCP] Framework draft question =09 =09 The performance of even the most optimized implementation of a protocol on an OS, a generic CPU and I/O platform will degrade with the messaging load. Hence what guideline is being provided here is doubtful. I don't quite know who would develop any an implementation that was purposefully slow, and it's equally doubtful as to what would happen should the 10s of ms requirement below not be met (will the protocol break? Will the use-fullness of the protocol disappear?) =20 Cheers, Woj. ________________________________ From: HaagT@telekom.de [mailto:HaagT@telekom.de]=20 Sent: 14 April 2009 11:36 To: Wojciech Dec (wdec); Sven.Ooghe@alcatel-lucent.be; ancp@ietf.org Subject: AW: [ANCP] Framework draft question =09 =09 Hi, =20 you're right that this is a performance requirement.=20 But I think this is an important requirement which has impact on protocol design and gives some developing guideline.=20 So I would propose to keep it. =20 Regards =20 Thomas ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec (wdec) Gesendet: Donnerstag, 9. April 2009 11:21 An: OOGHE Sven; ancp@ietf.org Betreff: Re: [ANCP] Framework draft question =09 =09 FWIW, my opinion is that this requirement isn't for a framework as it is a performace requirement that depends on a large number of things. I'd say drop. =20 -Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of OOGHE Sven Sent: 06 April 2009 15:41 To: ancp@ietf.org Subject: [ANCP] Framework draft question =09 =09 Hi,=20 I would like to raise a question regarding draft-ietf-ancp-framework-08.=20 Section 4.1 states "The ANCP MUST allow fast completion of a given operation, in the order of magnitude of tens of milliseconds."=20 This is as such not a protocol requirement, but rather a requirement on the platform choice (e.g. CPU speed).=20 I am soliciting feedback what to do with this (drop / reword / keep).=20 Regards,=20 Sven=20 ------_=_NextPart_001_01C9CC8C.12795852 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Framework draft question
Hi Sven,
 
that's fine by me. As soon as we close this one, please publish = an=20 updated version of the draft which we will then launch into the next = step of the=20 review process.
 
Cheers,
Woj.

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of OOGHE = Sven
Sent:=20 04 May 2009 09:36
To: Wojciech Dec (wdec); HaagT@telekom.de; = ancp@ietf.org
Subject: Re: [ANCP] Framework draft=20 question

Woj, Thomas,
 
In my view, the requirement is basically = saying that=20 it must not hamper fast completion of ANCP operations when required. I = cannot=20 find anything in the protocol that would result in a slow completion = of an=20 operation.
 
Are you aware of specific timers that would = result in=20 slow transactions? If not, I think it's better to refer to the = behavior of the nodes that run the ANCP=20 protocol.
 
I propose to reword the requirement=20 to:
 
- The Access Node must be designed to allow = fast=20 completion of ANCP operations, in the order of magnitude of tens of=20 milliseconds.
- The NAS must be designed to allow fast = completion=20 of ANCP operations, in the order of magnitude of tens of=20 milliseconds.
 
Let=20 me know if you are ok with this.
 
Regards,
Sven
From: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Sent: dinsdag 14 april 2009=20 15:50
To: HaagT@telekom.de; OOGHE Sven;=20 ancp@ietf.org
Subject: RE: [ANCP] Framework draft=20 question

The performance of even the most optimized implementation of = a protocol=20 on an OS, a generic CPU and I/O platform will degrade with = the=20 messaging load. Hence what guideline is being provided here is=20 doubtful. I don't=20 quite know who would develop any an implementation that was = purposefully slow,=20 and it's equally doubtful as to what would happen should the 10s of ms = requirement below not be met (will the protocol break? Will the = use-fullness=20 of the protocol disappear?)
 
Cheers,
Woj.

From: HaagT@telekom.de=20 [mailto:HaagT@telekom.de]
Sent: 14 April 2009 = 11:36
To:=20 Wojciech Dec (wdec); Sven.Ooghe@alcatel-lucent.be;=20 ancp@ietf.org
Subject: AW: [ANCP] Framework draft=20 question

Hi,
 
you're right that this  is a = performance=20 requirement.
But I think this is an important = requirement which has=20 impact on protocol design and gives some developing guideline.=20
So I would propose to keep = it.
 
Regards
 
Thomas

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec=20 (wdec)
Gesendet: Donnerstag, 9. April 2009 = 11:21
An:=20 OOGHE Sven; ancp@ietf.org
Betreff: Re: [ANCP] Framework = draft=20 question

FWIW, my opinion is that this requirement isn't for a = framework=20 as it is a performace requirement that depends on a large number of = things.=20 I'd say drop.
 
-Woj.

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of OOGHE=20 Sven
Sent: 06 April 2009 15:41
To:=20 ancp@ietf.org
Subject: [ANCP] Framework draft=20 question

Hi,

I would like to raise a question = regarding=20 draft-ietf-ancp-framework-08.

Section 4.1 states "The ANCP MUST = allow fast=20 completion of a given operation, in the order of magnitude of tens = of=20 milliseconds."

This is as such not a protocol = requirement, but=20 rather a requirement on the platform choice (e.g. CPU = speed).

I am soliciting feedback what to do = with this=20 (drop / reword / keep).

Regards,
Sven =

------_=_NextPart_001_01C9CC8C.12795852-- From root@core3.amsl.com Wed May 6 06:15:01 2009 Return-Path: X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EC34328C2BD; Wed, 6 May 2009 06:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090506131501.EC34328C2BD@core3.amsl.com> Date: Wed, 6 May 2009 06:15:01 -0700 (PDT) Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-framework-09.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 13:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks Author(s) : S. Ooghe, et al. Filename : draft-ietf-ancp-framework-09.txt Pages : 51 Date : 2009-05-06 The purpose of this document is to define a framework for an Access Node Control Mechanism 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. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather using a direct device-device communication. This allows for performing access link related operations within those network elements, while avoiding impact on the existing OSS systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ancp-framework-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-06061245.I-D@ietf.org> --NextPart-- From Sidd.Aanand@ecitele.com Thu May 7 12:17:21 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0A4D28C327 for ; Thu, 7 May 2009 12:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=1.599, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgPhTKL6QBAd for ; Thu, 7 May 2009 12:17:20 -0700 (PDT) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id 200843A70CC for ; Thu, 7 May 2009 12:16:47 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by ilptiron01.ecitele.com with ESMTP; 07 May 2009 22:15:35 +0300 Received: from ilptexch01.ecitele.com ([172.31.244.40]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 22:18:11 +0300 Received: from ilptextms01.ecitele.com (147.234.245.175) by ilptexch01.ecitele.com (172.31.244.40) with Microsoft SMTP Server id 8.1.358.0; Thu, 7 May 2009 22:18:11 +0300 Received: from USPITMAIL02.ecitele.com ([10.0.0.30]) by ilptextms01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 22:18:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CF48.8DECE82B" Date: Thu, 7 May 2009 15:18:51 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question regarding Capability negotiation Thread-Index: AcnPSKeEpqmGYGlXQPmVFqQxNw+72g== From: Sidd Aanand To: X-OriginalArrivalTime: 07 May 2009 19:18:10.0881 (UTC) FILETIME=[8F7EB310:01C9CF48] Subject: [ANCP] Question regarding Capability negotiation X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 19:17:21 -0000 ------_=_NextPart_001_01C9CF48.8DECE82B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 Section 5.3 of the current ANCP draft talks about Capability negotiation. It says that if a receiver can't support a capability in the received message, it will send an updated adjacency message with that capability turned off. This process will eventually result in both ends resolving the commonly supported capabilities. My question is, when the receiver sends the adjacency message with the updated capabilities, should it send the code as SYN or SYNACK? =20 Thanks, Sidd ------_=_NextPart_001_01C9CF48.8DECE82B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
Section 5.3 of the=20 current ANCP draft talks about Capability negotiation. It says that if a = receiver can't support a capability in the received message, it will = send an=20 updated adjacency message with that capability turned off. This process = will=20 eventually result in both ends resolving the commonly supported = capabilities. My=20 question is, when the receiver sends the adjacency message with the = updated=20 capabilities, should it send the code as SYN or = SYNACK?
 
Thanks,
Sidd
------_=_NextPart_001_01C9CF48.8DECE82B-- From anira@cisco.com Thu May 7 21:13:51 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2B63A6B14 for ; Thu, 7 May 2009 21:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+rkPEx4-1pg for ; Thu, 7 May 2009 21:13:50 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BA1433A681A for ; Thu, 7 May 2009 21:13:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,315,1238976000"; d="scan'208";a="300667192" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 08 May 2009 04:15:19 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n484FJa5032549; Thu, 7 May 2009 21:15:19 -0700 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n484FIAt016479; Fri, 8 May 2009 04:15:18 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 May 2009 09:45:17 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 May 2009 09:45:16 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Question regarding Capability negotiation Thread-Index: AcnPSKeEpqmGYGlXQPmVFqQxNw+72gASLM0w References: From: "Aniruddha A (anira)" To: "Sidd Aanand" X-OriginalArrivalTime: 08 May 2009 04:15:17.0593 (UTC) FILETIME=[981CB490:01C9CF93] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1138; t=1241756119; x=1242620119; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=anira@cisco.com; z=From:=20=22Aniruddha=20A=20(anira)=22=20 |Subject:=20RE=3A=20[ANCP]=20Question=20regarding=20Capabil ity=20negotiation |Sender:=20; bh=L2kX+8d5eOzhem3i5TEwQiJ6uf6sgmMsA/uAkBHCYkg=; b=BBbCbQAOdynpyMJd/YZOgP93qzaQC0VYeZHQcDVqR48Dw+OEMsoGhdgEZN 9kALjBrShiHow5yCeGFUx82kO/Wg+k9Pthu/LS3CcjVPBr6LxObacSe7nuUL Xc7qY/+7DZ; Authentication-Results: sj-dkim-3; header.From=anira@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: ancp@ietf.org Subject: Re: [ANCP] Question regarding Capability negotiation X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 04:13:51 -0000 Hi Sidd, =20 The new capability set it sent as SYN message. The procedure is:=20 On receiving a SYN,=20 if receiver finds that the sender supports more capabilities,=20 receiver waits for a new SYN if sender does not support all capabilities of the receiver,=20 receiver turns-off un-supported capabilities and sends a new SYN. =20 -- Regards, Aniruddha. A =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Sidd Aanand Sent: Friday, May 08, 2009 12:49 AM To: ancp@ietf.org Subject: [ANCP] Question regarding Capability negotiation Hi All, =20 Section 5.3 of the current ANCP draft talks about Capability negotiation. It says that if a receiver can't support a capability in the received message, it will send an updated adjacency message with that capability turned off. This process will eventually result in both ends resolving the commonly supported capabilities. My question is, when the receiver sends the adjacency message with the updated capabilities, should it send the code as SYN or SYNACK? =20 Thanks, Sidd From Sidd.Aanand@ecitele.com Fri May 15 07:19:03 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C3A828C313 for ; Fri, 15 May 2009 07:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvRHVT6X-npa for ; Fri, 15 May 2009 07:18:56 -0700 (PDT) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id E9C8A3A6E27 for ; Fri, 15 May 2009 07:18:55 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by ilptiron01.ecitele.com with ESMTP; 15 May 2009 17:17:34 +0300 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 May 2009 17:20:28 +0300 Received: from ilptextms01.ecitele.com (147.234.245.175) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server id 8.1.358.0; Fri, 15 May 2009 17:20:28 +0300 Received: from USPITMAIL02.ecitele.com ([10.0.0.30]) by ilptextms01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 May 2009 17:20:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9D568.4A36A4C9" Date: Fri, 15 May 2009 10:20:25 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Typo in Ancp protocol draft? Thread-Index: AcnVaEo04k/DJgz5SvCi07rH2ZsbVw== From: Sidd Aanand To: X-OriginalArrivalTime: 15 May 2009 14:20:28.0043 (UTC) FILETIME=[4BB7EDB0:01C9D568] Cc: "Keith A. Monahan" Subject: [ANCP] Typo in Ancp protocol draft? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 14:19:03 -0000 ------_=_NextPart_001_01C9D568.4A36A4C9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 In section 5.4.2 of draft-ietf-ancp-protocol-05.txt, when describing the fields of the event message, the code field is incorrectly referred to as a 8-bit value. As shown in figure 12, it should be a 12-bit value. This is one of the modifications from the GSMP RFC. =20 Thanks, Sidd ------_=_NextPart_001_01C9D568.4A36A4C9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
In = section 5.4.2 of=20 draft-ietf-ancp-protocol-05.txt, when describing the fields of the event = message, the code field is incorrectly referred to as a 8-bit value. As = shown in=20 figure 12, it should be a 12-bit value. This is one of the modifications = from=20 the GSMP RFC.
 
Thanks,
Sidd
------_=_NextPart_001_01C9D568.4A36A4C9-- From roberta.maglione@telecomitalia.it Mon May 25 01:57:21 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9533A692C for ; Mon, 25 May 2009 01:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.881 X-Spam-Level: * X-Spam-Status: No, score=1.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+6dg6RRs8TM for ; Mon, 25 May 2009 01:57:20 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id 24BC13A6814 for ; Mon, 25 May 2009 01:57:20 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 25 May 2009 10:58:49 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Mon, 25 May 2009 10:58:49 +0200 From: Maglione Roberta To: 'Sidd Aanand' Date: Mon, 25 May 2009 10:58:48 +0200 Thread-Topic: Typo in Ancp protocol draft? Thread-Index: AcnVaEo04k/DJgz5SvCi07rH2ZsbVwHrmBxA Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3E60EF353E@GRFMBX704BA020.griffon.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ancp@ietf.org" , "Keith A. Monahan" Subject: Re: [ANCP] Typo in Ancp protocol draft? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2009 08:57:21 -0000 Thanks Sidd for catching the typo, we will correct it in the next version o= f the draft. Regards, Roberta ________________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Sid= d Aanand Sent: Friday, May 15, 2009 4:20 PM To: ancp@ietf.org Cc: Keith A. Monahan Subject: [ANCP] Typo in Ancp protocol draft? Hi All, In section 5.4.2 of draft-ietf-ancp-protocol-05.txt, when describing the fi= elds of the event message, the code field is incorrectly referred to as a 8= -bit value. As shown in figure 12, it should be a 12-bit value. This is one= of the modifications from the GSMP RFC. Thanks, Sidd Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From root@core3.amsl.com Wed May 27 08:45:01 2009 Return-Path: X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 615FB3A6F38; Wed, 27 May 2009 08:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090527154501.615FB3A6F38@core3.amsl.com> Date: Wed, 27 May 2009 08:45:01 -0700 (PDT) Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-framework-10.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 15:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks Author(s) : S. Ooghe, et al. Filename : draft-ietf-ancp-framework-10.txt Pages : 52 Date : 2009-05-27 The purpose of this document is to define a framework for an Access Node Control Mechanism 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. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather using a direct device-device communication. This allows for performing access link related operations within those network elements, while avoiding impact on the existing OSS systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ancp-framework-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-27084231.I-D@ietf.org> --NextPart-- From wdec@cisco.com Wed May 27 10:17:50 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA4E3A6AF8 for ; Wed, 27 May 2009 10:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.899 X-Spam-Level: X-Spam-Status: No, score=-9.899 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mu6qOa-mHXLl for ; Wed, 27 May 2009 10:17:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 619253A6C8C for ; Wed, 27 May 2009 10:16:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,260,1241395200"; d="scan'208";a="41498741" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 27 May 2009 17:16:01 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4RHG1jO013305 for ; Wed, 27 May 2009 19:16:01 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4RHG1b2026209 for ; Wed, 27 May 2009 17:16:01 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 19:16:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 19:15:58 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ancp-framework-10.txt PROTO statement Thread-Index: AcmWe15+3A5iDMImRQ+JqNvc5wvTOhEOFZowAQ7COfA= From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 27 May 2009 17:16:01.0760 (UTC) FILETIME=[CF429600:01C9DEEE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7038; t=1243444561; x=1244308561; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20draft-ietf-ancp-framework-10.txt=20PROTO=20stat ement |Sender:=20; bh=BEifh5kFwMy1ZnR5+NRLte2gOxzEqeUEuNjUpGeiosA=; b=jScDuwBioFKSK9LdMORxYbuB7bHj3fEmAnOO2j+FfMth6tSBOkhP6QqNYb ERPFfnX88tgSkjfr5R8/B7mGxTIeKvg0d1+YClsR2wh70RhekCJM5PXGmdyL xD8xHFiTPN; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [ANCP] draft-ietf-ancp-framework-10.txt PROTO statement X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 17:17:50 -0000 draft-ietf-ancp-framework-10.txt=20 Document Shepherd Write-Up=20 (1.a) Who is the Document Shepherd for this document? Has the=20 Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 version is ready for forwarding to the IESG for publication?=20 Wojciech Dec (wdec@cisco.com).=20 Yes, I have reviewed the document and I believe it is ready for forwading to the IESG.=20 (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that=20 have been performed?=20 Yes, the document has received adequate review. The document received in depth review from five reviewers nominated by the WG as well as comments during WG last call.=20 =20 (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML?=20 No. (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director=20 and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue.=20 No specific concerns.=20 (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it?=20 The document represents WG consensus and has been reviewed by a good number of active WG participants. The WG has arrived at a state of consus regarding the content of this document. =20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.)=20 None indicated.=20 (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See=20 http://www.ietf.org/ID-Checklist.html and=20 http://tools.ietf.org/tools/idnits/ ). Boilerplate checks are=20 not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews?=20 The document satisfies all ID nits and uses a pre-5378 boilerplate because it was originally submitted prior to the change in boilerplate requirements.=20 This is an informational framework document and as such it was not subject to MIB doctor or other detailed technology reviews, but it has been reviewed by the WG. (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967].=20 Yes, the references are split appropriately. The security considerations includes a reference to a draft intendeded to progress in parallel, draft-ietf-ancp-security-threats, that will need to be updated as both documents get published. (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation?=20 The IANA considerations section esists and is consient with the content of the document. No requests to IANA are required. (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker?=20 There are no sections that use a formal language.=20 (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the=20 "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 The Access Node Control Protocol (ANCP) aims to communicate QoS-=20 related, service-related and subscriber-related configurations and=20 operations between a Network Access Server (NAS) and an Access Node=20 (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The=20 main goal of this protocol is to allow the NAS to configure, manage=20 and control access equipments including the ability for the access=20 nodes to report information to the NAS.=20 =20 The present document lays down an informational framework for the protocol to follow. It describes the ANCP use-cases and likely usage scenarios as well as outlining the functionality that the protocol will have to provide to support these. This document is a product of the ANCP working group.=20 This document is INFORMATIONAL.=20